February 9, 2012 in Development
Since early December I’ve been working on a large web application at work which will be a part of a larger series of web applications for our hotels and restaurants to use (yes, I am being vague for a reason). Let’s just say that there’s some very exciting stuff coming!
Throughout the process, I’ve been taking a little extra time here and there to try to make sure we are delivering the best possible experience for our users. Although I’m the only developer on the project, I’ve gone back and forth in discussions with colleagues, read through numerous blogs (eg. Signal vs. Noise) and forums (eg. Stack Overflow and its counterpart, User Experience). Here are some things from the aforementioned resources that I’m trying to pay particularly close attention to:
- Application Speed: Let’s face it, these days no one wants to wait for something to load. Users want their information quick. In web apps, there are a number of things you can do that help:
- Reducing data load times: This includes reducing calls to the database (caching, anyone?) and reducing the amount of data to what you actually need to have to do function X. The ORM I’m using takes advantage of lazy loading which helps when you’re calling objects that have numerous related (oh, and they each have numerous related objects). I’ve learned to use these mechanisms to my advtange in systems like these.
- UI Consistency: Nothing bugs me more than using an application (be it web apps, iOS, desktop etc) where the user interface changes from section X to section Y. If I’m looking at a list, I expect the screen to be laid out in a consistent manner each time. I don’t want the search on top on X and in the bottom right corner on Y. My personal preference is always to have the search above the grid. Keeping the “Add new item,” or “back to list” links or buttons in the same spot across screens is also key (read more from Smashing Magazine). User input forms are also a great time to be consistent in flow. I would say this is an ideal time for some designer-developer collaboration.
- Work Flow: I think this kind of coincides with the UI consistency, but make sure the user’s steps across sections are consistent (as much as they can be). If a user can add a customer by hovering over “Customers” in the main navigation, make sure they can add a contact the same way. I like to think of things like Outlook; each section (mail, calendar, contacts, etc) is consistent but there’s also shortcuts (hint: users love shortcuts, but make sure to let them know about those).
- Keep Changes to a Minimum: (after initial launch). Jason Fried from 37signals recently wrote a post about how SaaS (Software as a Service) platforms are harder and harder to change as time goes on. Our products (applications) are essentially being offered as SaaS solutions, so this applies to us. Users [humans] are creatures of habit. We don’t like change. Wait, most of us hate change. This is one major reason I’m trying to work as hard as possible to create that great (and consistent) UI now, before it’s too late. 37signals solved this problem by launching a whole new version of their flagship product Basecamp.
- Resist Scope Creep: Scope creep = death. To me, it comes in one of two forms: a) I (yes, me, the developer) decide “Oh, I think this is a cool idea, I think I should add it to _____; and b) User A comes and says “We ‘need’ functions D, E and F in addition to A, B and C. Okay, if you needed those, you should have defined them in the scope up front. Then it comes to the decision of key people (eg, project managers, managers, developers, etc) to determine whether the item(s) is worth pushing the deadline out to deliver. Does it need to be done now or can it be in the next release? I’ve had to learn (and still am, with a long ways to go) to manage user expectations and requests.
- Manage Environment Transitions: What do I mean by this? Don’t update something in your code (“oh, but it’s just a quick fix.” Don’t care.) and push it straight to production. The last thing you want is for that “quick little fix” to break your application for everyone. We’re going to have three separate instances of our application(s) running. Development: This will be used for myself and the designer to push stuff temporarily to test it as we’re developing. I am using Visual Studio so I see things locally too, but it’s good to have it in the server environment. Test: Once things have been stable in Development, we’ll move them into Test for others to test. Production: This is the gold one. All your users see this; you want it to be stable as much as possible. I know this workflow may seem like a lot, but it’s a common one, and will reduce the number of issues and complaints from your users.
These are just a few thoughts I’ve had in my head over the past couple weeks. Feel free to leave some comments letting me know what your thoughts are!