Our post on Wednesday described an announcement by Proxibid of their forthcoming embedding bidding service. This service will allow auctioneers to seamlessly embed Proxibid’s systems into the auctioneers’ web pages. In Wednesday’s post, we posed five questions we felt were important to ask of Proxibid and other providers who are looking to offer this type of service. Here’s a recap of the questions we posed.

• Pricing structure – will it cost more to use the embedded solution?
• Simultaneous exposure – will inventories exist on the portal and the auctioneers’ websites simultaneously?
• Branding – will the bidding experience be non-branded or simply embedded?
• Difficulty – how easy will it be for auctioneers to integrate the bidding system within websites?
• Customer pooling – what will the bidder registration process look like and how will buyer information be shared?

We were contacted by Tom Clark, Proxibid’s Chief Operating Officer, and in a phone call this morning he answered these questions.

Pricing structure
Proxibid will not alter its pricing structure for auctioneers who elect to use embedded bidding. “Everybody gets it,” said Clark.

Simultaneous exposure
Items listed on auctioneers’ websites will also benefit from the exposure on proxibid.com. This simultaneous exposure means an auctioneer’s bidders can place bids on xyzauction.com and Proxibid’s existing customer base can place bids on proxibid.com.

Branding and customer pooling
Clark made it clear that Proxibid’s goal was to provide a wholesale product that could be seamlessly integrated into an auctioneer’s website. The Proxibid logos, headers and footers will be removed, providing a user experience that feels congruent with the auctioneer’s site. Clark said that the goal was to remove the Proxibid branding from everywhere except where it would be required for legal reasons, such as upon registration where users must agree to Proxibid’s terms and conditions. Any existing Proxibid bidder will be able to participate in embedded bidding after meeting the requirements for the event set by the auctioneer without having to create a new account. Proxibid will be exploring allowing the ability for an auctioneer to further customize the pages with CSS and perhaps embed a logo into the bidding application, but those advanced customization options my not be available until future releases.

Difficulty
Clark said that Proxibid’s goal has been and will continue to be to “provide solutions that are economically viable and make sense.” With this regard, it is important that the embedded service be usable by the greatest number of Proxibid’s auctioneer clients. By using frames to include the inventory listings, anyone with a rudimentary knowledge of website design will be able to easily utilize the service and users won’t be confused by changing domain names.

All in all, we think these are the answers auctioneers were hoping for and we look forward to reviewing this service, as well as those from other providers, in the months ahead.

I’ve spoken with many auctioneers recently who are at the beginning stages of a new technology project, usually a website redesign or new build of some kind. The questions everyone asks mostly revolve around the expectations they should have of the person or company being hired to build the website.

A mockup is essential to give to your provider - don't let the provider design the site

I’ve put together some content that I consider important to include in an RFP – request for proposal. It’s by no means exhaustive, and at least some parts of it will have to be changed for every application, but it’s a start to a baseline set of what I believe to be good standard practices when entering into a relationship with a service provider.

For the purposes of this post, buyer is auctioneer, seller is service provider, employee is a backend user and user is frontend user. We’re going to assume that the buyer will provide a mock-up created by a designer. This mock-up would show exactly the layout and presentation requested by the buyer so that all the seller has to do is build the site using web standards. This draft assumes that your provider will install the website on a purchased or rented server controlled by the buyer. It assumes that the buyer has an email list system – I recommend phpList – and wants ownership of the auction calendar as opposed to using a third party’s auction calendar like that from Auction Services or AuctionZIP. I’m neither endorsing nor recommending against either of those popular auction website providers, I’m merely giving an example of a possible permutation. Perhaps a third party calendar is desired, as well as housing the site on the seller’s servers. Each auctioneer’s needs and desires are different.

I’ve intentionally tried to stay away from most functional pieces of a good website and focus instead on the deliverables and legal requirements that should set the ground rules of a work for hire.

Website must include a calendar system that will facilitate easy creation and display of auction title, date, time, location and thumbnail images. Frontend layout is provided by attached mock-up. Backend must allow upload of images, auction event creation and modification and be available only over secure connection. Seller must install security certificate on buyer’s environment if it doesn’t already exist. Backend login must be employee-specific with ability to grant access to various resources to various employees.

Email subscription form must allow direct subscription ability and integration with a bulk email list management system such as phpList or Intersend.

Sales lead generation form must email leads to email address or addresses as specified by buyer or employees in the backend.

In order to anticipate future browser compatibility we require conformance to the following W3C standards.

1. Markup must validate to the W3C’s XHTML 1.1 doctype at http://www.w3.org/TR/xhtml11/
2. Style sheets must validate to the W3C’s CSS 2.1 format at http://www.w3.org/TR/CSS21/
3. Javascript will never use browser detection but instead object detection to test for browser support of properties, arrays and methods.
4. Site must not use tables for layout purposes. Tables will only be used for tabular data.
5. Website must be tested to display similarly in current and the last major release of Internet Explorer, Mozilla Firefox, Apple Safari, Opera, Konqurer, and Google Chrome on stock installations of Microsoft Windows XP and Vista, Apple OS X and Ubuntu Linux where each browser is available on each operating system, as well as Internet Explorer 5 and 6.

Deliverables:

1. All deliverables must be installed by seller on buyer’s environment.
2. All deliverables will be considered “work made for hire” under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. Any use of open-source content must be expressly defined and agreed to by buyer before implementation.
3. No dependence on outside services is allowed. The website must function completely and independently of any third party site, service or server, unless expressly permitted by buyer.
4. Seller will have no rights to use, reproduce or access any content, materials or other information stored on the website, including but not limited to form submission, customer information, email addresses, sales data and account records.
5. Work must be original and not based on existing templates or previously-constructed components used by other customers of the seller.

Successful proposal will include the following components.

1. Bid for construction of website using web standards with layout defined by provided mock-up and functionality defined above. This construction must include documentation and training sufficient for buyer to understand and operate site completely and effectively.
2. Estimate of time to completion as well as financial implications of delays should they occur due to additional requests made by buyer or developmental hardships experienced by seller.
3. Bid for continued ad-hoc support and maintenance on an hourly basis. Support must be provided by website creator if that person is different from seller.
4. List of hours with guaranteed availability for support.
5. List of five websites created by seller and contact information of website owners to serve as list of references.

Now, I realize that this draft is very strict. Some providers may balk completely, and some that don’t balk may intentionally price themselves out of the competition because, like using perfect English, using web standards is hard for some. Hopefully, however, this example may serve as a valuable starting point for someone looking to start from scratch. Compromises may be desired on certain parts, like XHTML validation, but an auctioneer should always retain the rights to your data (deliverable 4) and be sure that the provider will support the product after it’s built. Above all, be sure to have a very clearly-defined, counsel-approved contract that you can use to hold the service provider accountable should you believe that the work is incomplete or incorrect.

Writing an example RFP was requested by many. These are some of my ideas. Do you have a must-have condition for the work that you hire done? Leave a comment so we can build on this document and add it to the resources page.

Image via Wikipedia

Portable Document Format (PDF) is a file format created by Adobe in 1993. As of July 1, 2008, it’s an ISO standard, which means that the format is open and published so that anyone can create it or use it.

There are many misconceptions about the proper use of PDFs, and today I’m going to try to explain how to properly use PDFs on the Internet. Monday I’ll give a couple of faster, easier alternatives to Adobe’s bloated Reader product and discuss some tools to create PDFs without having to use Adobe’s obscenely expensive Acrobat product.

The advantage that PDF has over other file formats is that it’s a good way to represent printed material exactly as the designer intended it. This advantage makes it good to use for contracts and brochures where the user doesn’t need to change the content and is willing to jump through some extra hoops to view the content in a layout that approximates the printed page. It’s a great format for designers to send to printers because it ensures that the content is displayed exactly as the designer intended.

The disadvantage that PDF has is on the Internet. The Internet isn’t a format that is supposed to resemble the printed page. Because the PDF format – for good reason – isn’t supported by any browser, the user must use a browser plug-in to view the content, souring the browsing experience. For this reason, the use of PDFs on websites should be limited to an optional content delivery mechanism.

An example of a very bad use of PDF is for a website selling real estate. The designer used PDF to send the property information document to the printer. The PDF is uploaded to the website and a link is placed on a sparse page that says “download property information document” for information about this property. This breaks the first rule of accessible website design, which is don’t force the user to use a plug-in or add-on to view content. Most browsers with the plug-in installed open the page in a new tab, breaking another first rule of web design which is don’t open new tabs or windows. Search engines index PDFs, but if you click on a search result that is a PDF you’ll be taken straight to the PDF which lacks a navigational system for the user to get to your main website.

An example of a very good use of PDF is for the same website to have every piece of information within the property document delivered as valid XHTML / CSS on the website page with an optional download for users who want to physically print the information about the property. In this case, the user can browse the property information at browser speeds rather than having to wait for and be confused by the loading of a plugin. Even the example property contracts should be first delivered on the website and also made available as PDF for users who want that method as an option.

The very best use of PDF is to not use it at all, delivering the content by XHTML and the layout by two style sheets, one CSS for the screen and one print style sheet, so that the website looks one way on the screen but when the website is printed it looks like the property information document. This is a more advanced website design technique that I’ll try to cover later.

To summarize, PDF has its uses. Just remember that as a content delivery system on the Internet it falls short.

Flash is a very bad way to build websites. It’s not only about SEO. It’s about usability. For the same reasons that mature developers don’t use “fly-out” or “drop-down” menus, you shouldn’t use Flash because it requires you to do one of two things. You can either alienate the growing minority of users using alternative user agents or you can “sniff” to find out what the user is using and deliver one site if the user is using Firefox on a Mac and another site if the user is browsing using Internet Explorer on Windows Mobile. Either option is a bad decision.

Properly designed websites keep usability in mind for 100% of possible users. They’re made with semantically valid XHTML and CSS. They don’t start animation or sound without the user clicking somewhere to request it. They don’t require the user to download something special like Flash or Java. They load faster because of the lighter page weight caused by separating the markup (XHTML) from the layout (CSS). They have a good navigational structure that doesn’t rely on drop-down or fly-out menus. They can be browsed effectively with a text-based browser or screen reader. They are very well-indexed on search engines because they’re so accessible.

Flash does have one redeeming quality. It is the current, defacto standard for video distribution. Until Silverlight gets out of diapers, it appears we’re stuck with Adobe’s pile of steam for now.