Since Adam McCrea has introduced his solution for simplifying HTML mockups over on the EdgeCase blog, I thought I would take the time to reintroduce my own: Serve.
I’ve been using Serve for almost a year now to prototype MemberHub and before that I used various forms of a simple Ruby script to power my HTML mockups.
Serve has become an indispensable part of my development methodology because it allows me to prototype the application using HTML in a DRY format independently of the work that is being done by developers. This independence is essential as we explore various facets of an application and prioritize the parts that should be developed first.
To give you an idea of how it has worked on MemberHub. I sit down with the client beforehand and discuss a feature and the initial user stories that make up that feature. On a large feature I may spend some time during this phase drawing up a couple of paper prototypes so that we can get a general idea of the shape of the feature and how it will affect the application. We can then use the paper prototypes to give a client a fairly reliable estimate of how long it will take to do the initial development.
Once the feature has been outlined in this way I can then begin work with the HTML prototype. I tend to start with the HTML prototype and not in a graphics program as it allows me to focus on the functionality without getting too caught up with how it looks initially. (I may drop back to a graphics program and “punt”, so to speak, if I’m having trouble getting the layout just right for a particular screen.)
Often while I’m working on a screen for a particular section, I will call the client over (yes, I love working onsite with my clients) and ask for their input on how it flows and feels. One of the chief advantages of developing an HTML prototype for your application is that it gives you the opportunity to explore the flow of your application before the backend development has begun. Hopefully, during the prototyping phase you will be able to iron out any problems in flow, with minimal expense because there is no backend to rework.
The “Design First” approach is huge for us, because most, if not all, of the business decisions are ironed out in the design phase. Also at the point that a feature has passed completely through the design phase we can then estimate that feature with extreme accuracy. The client also knows exactly what they are going to get when the development is done.
Once the client has signed off on a feature in the prototype, it can then be thrown over the wall to the development team. Because we use Serve, the views can be copied over from the HTML prototype to the application almost as is. This does take some effort on my part to construct the views in a way that is friendly to a Rails application, but in general this is not hard if you understand the RESTful approach that Rails encourages. This process is also eased because Serve has full support for partials and layouts with either ERB or HAML.
Does the developer find it annoying to have to copy the views over from the prototype into the application instead of having the designer work with him in the application? In general, yes and no. Yes more work is involved in copying views over into the application (particularly when views change because a feature is revisited). But no, because he doesn’t have to worry about a designer breaking tests or causing the application to fail in some way. It’s also hugely beneficial to the developer because the guesswork is taken out of a feature when it is completely developed (and signed off on) in the prototype before the development begins.
Also, I can’t emphasize enough the freedom that the two project approach gives the designer. No longer is he caught up with views that are hooked into controllers, etc… He can explore new features and focus almost completely on the HTML, CSS, and creative part of his job. With designers often juggling the roles of business analyst, creative expert, HTML/CSS/Javascript guru, asking for the two project approach small price to pay for the increased productivity.
I’ve put together a brief overview of Serve in screencast form below. Let me know what you think.
Since January of last year, I have been working with a small startup here in Raleigh building a web service called MemberHub. MemberHub has been a bit of a dream come true for me. It is the first time I’ve had the opportunity to build a subscription-based web service that has massive online appeal. If it takes off, I believe that MemberHub could be the next Facebook or LinkedIn.
Now don’t write me off just yet… Hear me out.
People use Facebook for their personal lives to help manage the relationships they have with friends. LinkedIn is useful for keeping track of your business connections. MemberHub is designed to help organizations, such as churches and nonprofits connect with their members and manage the various groups that make up the organization.
Using MemberHub, you can create online “hubs” for each of the groups that make up your organization. A hub is a simple online home for a group. It contains a home page, a calendar, a place for announcements, a discussion board/mailing list, and a place to upload files. A church, for example, could create hubs for each of its bible study groups, a hub for the homeless ministry, a hub for the singles ministry, a hub for the worship team… You get the idea.
Now the concept of a hub is nothing new. There are plenty of services online today that offer similar features. Many organizations are using services like Yahoo Groups or Google Calendar with great success. MemberHub’s chief strength—and differentiator—is that it provides these features in a way that is friendly to organizations and members.
For the organization, MemberHub makes it easy to setup and organize secure online homes for each of your groups. For the member, MemberHub makes it easy for you to keep up with multiple groups and even multiple organizations in one convenient location! One of the most incredible features of MemberHub is that it can take all of the events across all of the hubs you are affiliated with and display them on one convenient calendar. Imagine never having to enter events in for your organizational activities again!
We’ve really worked hard to make MemberHub simple and intuitive. Below is a brief, 6-minute video that will give you a bit of the bigger picture of what MemberHub can do for you:
If you’d like to learn more about MemberHub, visit http://memberhub.com. And do let me know if you have questions or comments.
Adam Williams and I are working on a new project together. It’s called AnnounceIt.
AnnounceIt is a super easy way to put up a teaser page on a domain to start collecting e-mail addresses. It’s great for an “Announcements Only” mailing list for an event, web site, or web application that is being developed. You can see an example of a “teaser page” for a Web application here and here (yes we are using it to announce our own web application).
If you’d like to be notified when we launch AnnounceIt, signup for our mailing list at announceitapp.com.
My good friend and partner Adam Williams has just finished bolting the doors on his new YAML-fixture-killing Rails plugin: Dataset. Dataset is the next generation of a plugin that Adam and I wrote last year called Scenarios.
Why the need for a new plugin? The Scenarios plugin was originally built inside of a Rails application that we were working on. At the time we threw it together rather haphazardly. There were few tests (if any). The main thing was to prove that the idea was good. Scenarios worked so well for us that we soon extracted it and used it in our next application. A friend added support for Test::Unit. Pretty soon the implementation our “simple” fixture replacement plugin had grown quite complex. It was becoming hard to maintain.
This year Adam and I have been working on a rather large Rails application. The run time for tests in our application had almost become unbearable. In an effort to speed up those tests and fix some of the outstanding issues in the Scenarios plugin, Adam decided to start from scratch and rewrite the plugin from the ground up using the test first approach.
We have christened the rewrite “Dataset”. It is virtually a drop-in replacement for the Scenarios plugin. Our initial tests suggest that it is significantly faster than its predecessor.
Folks our experience with it over the last year leads me to believe that Dataset is the solution to the Rails fixture debacle. If you haven’t tried it out yet give it a try!
This is the Web site of Wiseheart Design—a one-man design and programming
shop run by John W. Long. John is passionate about Web standards,
Ruby, test driven development, and people.
Read more…
As a member of the Ruby Visual Identity Team I helped redesign the main Ruby Web site. The site is one of the first major Web sites to be powered by Radiant.
Read the launch announcement over at ruby-lang.org.
