Sunday, July 26, 2009

Beginning Phase II, with new goals

We're gearing up to begin Phase II with new goals and new people! It looks like Mike Gunderloy and Russell Norris may be joining the project as contractors. Lee Feistel won a big contract with the University of Texas, migrating and re-coding a big PHP app, so that's sad for us but exciting for him! Fortunately, Lee is available to assist with server administration if we get in a jam.

Here are the new goals for Phase II (a reduction of goals to fit the budget):

-- a public-facing website design
-- ability to reserve equipment
-- ability to send email notifications
-- a targeted unit test suite

The first item is exciting and important. This will allow us to populate the new database with equipment and launch the site ahead of the application. To summarize, the new site requires ease of navigation with a minimalist layout (the goal being to help visitors easily find information). I'll write a separate post about these requirements.

The second item is the big one: given dates and times for pickup and return, present a list of equipment that is available based on partial text search criteria. Seems simple and it may well be. The only hitch could be the packages, making sure all the required children in a package are available. But hopefully that's where the nested set table comes in, to make this search easy (get all required children from the nested set table and then look them up in the reserved dates table).

The third item is fairly easy but there are a ton of notifications that need to fire upon finalizing a reservation, return of equipment and on a scheduled basis. These emails have been listed in an earlier post.

The fourth item is critical, as we do not have any tests yet. I'm convinced that tests are beneficial and I'm looking forward to getting a jump start on them so that more tests can be built as the project progresses.

Just to recap, we're using haml, sass, jQuery (unobtrusive Javascript), a virtual private Linux server and git. No other choices have been made regarding test framework or deployment. Rails plugins that the app currently uses or I want to use include:
-- resource_controller (was using, now using inherited_resources)
-- awesome_nested_set (using, I have a branch here)
-- input_css (still using?)
-- authlogic (want to use -- using now)
-- aasm (now in edge Rails)
-- acts_as_audited (want to use, or something similar)
-- paperclip (want to use)
jQuery plugins the app uses or I want to use include:
-- low pro (using)
-- form plugin (using)
-- date picker (want to use)

Website design requirements

The new site must be easy to navigate, easy to find information and easy on the eyes. "Don't make me think" is a good mantra for the design.

The view code is written in haml and the CSS is written in sass.

In general, we want to embrace as much convention as possible, regarding layout of navigation and page elements. And the layout should be familiar to some degree with our current site, as far as where the navigation elements are located (across the top and down the left side). The right side can contain new elements like a shopping cart.

Visitors to our site are primarily browsing for equipment items. (Quick summary: we rent equipment, so it's a lot like browsing for stuff to buy.)

We have new equipment arriving all the time and we run specials on a weekly and monthly basis, so we want a good way to advertise these items (maybe in the right column) or via an "Offers" or "Specials" button, to reduce the clutter.

Our store hours and policies may change at random, and we want to alert visitors to these changes (but only the first time they visit since the change went into effect).

Sites we think have good navigation are Newegg and B&H Photo. However, both these sites are waay too busy (which is understandable, given their range of inventory).

Both Newegg and B&H we like because visitors can filter their search results. Both sites present a good list layout.

B&H has a good layout when presenting the details of an item.

We like the Netflix "hover over something to get a summary detail screen" feature.

B&H has an example of alerts (for example, on Friday they are closed for Sabbath).

We like round corners but not pastel colors.

We like Vimeo's account sign up procedure. It's quick and painless.

We will have a "shopping cart" that allows visitors to create a custom package and submit it for a reservation. This will likely be in a separate phase, once we have the reservation system stable, but it's something that we want to add ASAP.

Most items will have images, most will have multiple images and some will have video tutorials. Items will have specifications, features, optional items and related items, much like B&H's items. There is a price per day, price for weekend, price for 5-day week and price for 7-day week that should be clearly visible all the time on the detail page. The list can show just the daily price but would be helpful to show the other prices, since they reveal that the item is much cheaper for longer retanls.

We like using Javascript to update pages as the visitor navigates through a list but realize that it's impossible to bookmark or email a link to an item. Maybe we use AJAX for everything except displaying the detail screen for a selected item. Or give visitors an "email this page" link or something. (FWIW, the reservation system will use AJAX heavily for speed and usability).

We need to decide whether or not to design for visitors who have disabled Javascript. We also need to decide whether or not to design visitors who disable CSS (if not too expensive, we want the site to be accessible by people who are visually impaired, but this is not a critical requirement).

We are undecided about a splash screen. But definitely, no flash. :)

Our phone number should be easy to find on every page (how to contact us should be easy to find).

Site maintainers need easy ability to edit text (preferably page text but especially equipment item text and preferably edit-in-place). Also, easy ability to upload images for equipment items.

Usability scenario:

A visitor enters our site and their first choice is which area do they need:
-- rentals
-- supplies
-- production crew
-- post-production
-- resources
-- contact

Lets assume they need to rent a camera and some sound equipment.

They start with the camera. They will know one of these things:
-- they want an HVX200
-- they want an HD camera
-- they want a specific make of camera (Sony, Panasonic, etc)
-- they want any camera that fits their limited budget
-- they don't know what they want

Since they want both a camera and sound equipment, they will likely appreciated a list of suggested packages that they can evaluate. If they select a suggested package, they will want the ability to remove items they don't need, to cut costs, and yet add them back when they realize they actually do need them.

They want the ability to store their selections in a shopping cart (again, something for a separate phase but we'll need that placeholder in the layout because hopefully it'll happen sooner than later).

Whenever the visitor is in the rental section, there should be an easy-to-find link to our rental policy and forms (both printable and online).

That's the basic scenario. For the other sections of the website, we'll tailor it to be similar to the rental section. Contact will have map, directions, hours, all that normal stuff.

Monday, July 6, 2009

Phase II -- new plugin to evaluate

[UPDATE: I've emailed Matthew and he recommends making sure the equipment hierarchy needs the complexity. Also, he's not actively maintaining his plugin and suggests using one of the nested set plug-ins like awesome_nested_set that we're using. So while a D-A-G could reduce the number of tables needed for this app, it's probably best to just carry on with the original plan.]

I'd like to evaluate this plugin for the equipment hierarchy, it's called "acts-as-dag" by Matthew Leventi.

/mieventi/acts-as-dag on github

It looks promising because it contains nice named scopes and allows multiple parents as well as multiple children. The searches are well thought out and it looks to be a fast interface (most calls are performed with one SQL call).

I'd hate to rip up the equipment tree at this point but now is the last time this could happen without it being a BIG deal. It might only disrupt the code a little. Still, the gain needs to be large enough to justify the disturbance.

The biggest problem I see with it is that it's not well maintained. It looks like Matthew created a year ago and then left it. One other person forked it and added to the code. So it looks like it might be immature but still, it looks attractive because of its capability for children to have multiple parents.