Jason Santa Maria's 24 Ways entry provides a very simple explanation of the modular layout strategy he uses. THe example html/css is super simple and easy to read, and the article itself is a short and easy to digest. We need to see more concise instructive articles like that.
I just came across two Growl-like alert plugins that should be of interest to HTML prototypers. Growl is a Mac OS X application that functions like a service that other applications can use to show unobtrusive messages in the monitor when things happen on the system.
The screenshot above shows the Window Growl plugin with 2 different types of messages in view.
Scribbles is perhaps the simplest drawing program I've ever tried. The app, created by atebits, gives you 4 tools: brush, move, pan, and zoom. There are 12 brush styles, a color picker, a big slider for brush size, and a layer manager.
It looks deceptively simple on the surface, but when you explore a bit, you'll find some really interesting functionalities that even the advanced Mac freehand drawing tools like Sketchbook and ArtRage don't do well. One is the tracing paper mode, which gives you a transparent canvas so you can position the window over anything on screen. The other is the infinite canvas, which lets you zoom out infinitely to widen canvas by just dragging a magnifying glass cursor. It's pretty wild, and you kind of get a sense of scale of your zoomed canvas when grids are on.
Seems like kind of a fun toy, but I'm sure you could do a lot more with this if you got creative.
Peter Flynn gives a demo of wireframing in Adobe Flash Catalyst, aka Thermo. Every online demo I've seen of this product looks more and more exciting, and this is truly going to give Mac users a way to do easy interactive prototypes as our PC brothers and sisters can do with tools like Axure. I fully expect to be using this thing when it gets out of Preview release. It's only slightly ironic that his first 5 minutes are talk about how wireframes are by definition, low fidelity, given my last post. :)
In Twitter today, I posted a message that I need to resist putting rounded corners on boxes in wireframes. Then I got a few replies essentially saying that stylized elements shouldn't be in wireframes. Context is everything. Taken out of context, it is very difficult to possibly critique a specific design technique without knowing the how and why you're using it. Because of that 140 character constraint in Twitter, I didn't really explain that this rounded corner example came from my hybrid high-fidelity wireframing and visual design document I was working on.
The above is an element in a wireframe. It's for a special kind of tag in Traction, the product I've been working on. They're for todo tags actually, and the element also doubles as a checkbox. If you click the checkbox, the To Do becomes a Done tag.
I'm only posting this entry now so people understand just what the hell I'm talking about in Twitter, and get the bigger picture with regard to what I've been playing at, with going from sketches to UI specs, because very often I skip the rough wireframe stage these days, and go right to design comp-quality elements in UI specs.
I wireframe fast. Faster than I work in Illustrator or Photoshop. I also do all of our XHTML/CSS. But it's still a hell of a lot faster for me to illustrate something in OmniGraffle. That's its purpose after all--it's a drawing program. It's for illustrating. Maybe it's static and it doesn't illustrate everything well, but when I need interactivity, then I do it some other way. But there are times when I find it does a hell of a job at illustrating visual design too.
My point is that there is a place for doing high fidelity in wireframes. The outie/innie distinction is good to point out here. In my situation, HiFi serves a purpose because I'm the one who goes from pencil sketch to implementation just short of hooking up the back end system functionality and AJAX. There are parts we do that go from sketch to implementation, or from discussion to implementation. But there are definitely parts where I do a HiFi wireframe because it's a more efficient path. 99% of the time, I'm not specifying/presenting to communicate an idea to a customer/client, I'm creating to both test out an idea with a design/dev team and to prep the way for graphic production on a visual design that's already been approved.
This discussion may seem out of left field, but it's something I do pretty regularly actually--go from Lo Fi at the onset of a project, to doing Hi Fi when visual design is there. So what's your take. Do you have a similar experience or treat wireframes differently than the majority of IA/IXD pros out there?
As many of my friends and colleagues know, I'm one of those people that read David Allen's Getting Things Done, got the religion, and tried various methods for planning and managing project tasks, using both software and paper. In the past few years, like many, I've tweaked my approach, taking bits and pieces from here and there to settle on the solution that's most suitable for the way I work. At this point, any resemblance to GTD might be less noticable, but it's beginnings are there.
The methods and tools that work best for me now are influenced by GTD, Niel Fiore's The Now Habit, and from a broader perspective, by ideas inspired by Napoleon Hill's Think and Grow Rich, which seems now to me to be less about planning your road to wealth, and more about how to use thought to visualize goals. Out of those kinds of ideas, stem the more practical suggestions of taking the larger goals and breaking them down into smaller tasks, a la the book How Do You Eat An Elephant: One bite at a time, which seemed to be recommended reading years ago to grad students.
In any case, the sum of everything I've taken from those books that I deem doable for me without being unreasonable. I do some of these with regularity, e.g. the high level planning, and others more loosely, e.g. the daily task list.
High and Mid Level Planning
This is the outline for a high level plan for a single project. Apply for each project, and iteratively apply to sub-projects. Revisit and revise based on changed goals in the daily/monthly/quarterly view. It's kind of a like a roadmap and is done at the above intervals.
- Set high level goals per project and record them. This can be done for both work and personal projects.
- Break the high level down into steps towards achieving that goal, and further break those down into smaller and smaller bits that can each be accomplished in one sitting. Each step should be ideally accomplishable in a specific time frame, e.g. up to 1 hour on 15 minute intervals with repeat attempts as necessary.
- Review the steps in the process, and record each step as a task or to do.
- Plot groups of tasks along a high level continuum, e.g. year, quarter, month
- I may also create a sort of radar and plot the projects on a 2x2 grid with a Y vector for importance/priority and an X vector for level of effort.
- Put your tasks in project folders (phsyical folders or in software like OmniFocus, Things, an Outliner, Word, etc.), and put in order when possible so that next actions are at the top.
Low Level Planning
This is the day to day work of getting things done.
- Check your project folders for next actions and list all the goals that need to be done today. GTD peeps call these tickle folders, and the practice is to check these frequently to see where you are.
- If anything is waiting for feedback or input from someone else, file it back in or defer it, but check in with people you're waiting on if you have to.
- With your list of goals for the day, mark estimated time to complete or level of effort.
- Start going down the list based on priority and level of effort and list tasks that you know you can complete for the day. Create a task list based on those "can do" actions, with estimated times to complete and checkboxes.
- Record tasks completed and time to complete.
- At the end of the day, plan your goals for the next day.
This is the ongoing planning I do every quarter and every month to set goals, and assess where I am with regard to the last month.
- As above, adjust the higher levels according to shifted actual goals.
That's a hell of a lot of stuff, and I haven't even included the idea of planning the things you want to do, a la Now Habit and Uncalendar. I don't do all of these. I do some of the above on paper in my sketchbook. At the top, I place my date and goals radar. Below, I list my tasks with checkboxes, level of effort/duration, and actual completion duration. I've actually been playing around with a task book based on this, which I print and bind myself.
Recently I've also been turned on to some great ideas that validate the above approach and give me ideas for how to better support this obsession with finding the method the works for me. One is Jack Cheng's idea for forward time tagging/estimation in your task list. And the other is David Seah's Printable CEO work sheets for tracking actual effort, and a Emergent Time Tracker Flash app he's developing to do time tracking, which is pictured above. I've been playing with it, and it's really quite nice. I'd be interested in using something like that full time on my Mac and iPhone. The Behance Network's Action Method is a nice web-based service that let's you do all of this online.
Anyway, now seemed like a good time to start sharing my thoughts on what works for me, mainly because I'm interested in hearing what works for other people. For now, I'm sticking to a combination of OmniFocus for the longer term planning and paper for the daily planning/tracking and it's working for me. It's been amazing to see how much people like to talk about this topic, but since Merlin's stopped talking about GTD on 43 Folders, maybe we'll stop talking so much about getting things done, and just get them done. Which reminds me, this blog entry has eaten up more than 30 minutes now.
At today's excellent Creative Mornings on physical computing, Zach Klein and Casey Pugh from Vimeo talked about tinkering with Arduino, an open-source electronics prototyping platform. They showed some simple circuit controls using the LEDs and Processing, and then demoed a Daft Punk helmet they created with LEDs, that could then be controlled/drawn on via a Flash UI. Neat stuff.
Later, I got to talk to Carl, a freelance developer/interaction designer who turned me onto NYC Resistor. NYC Resistor is a hacker collective with a shared space located in downtown Brooklyn where people meet regularly to share knowledge, and hack on projects together.
As a maker, I've been really interested in doing more to combine my craft hobbies with my techie and interface design interests. Resistor sounds like the kind of place I'd be able to do that, and I agree that more web people should play around in this area. Reminds me of some of the 1990's fusion of art/tech in NYC, ala adaweb, JODI, and Eyebeam.
Resistor sounds pretty cool. I've been looking for a reason to play with Processing, and looks like some Processing workshops are going on at the space.
"I don't want to develop a relationship with these guys. I just want to buy something." That's what some of your customers are saying when you ask them to register or sign in, and some of them will walk away with their dollars if you frustrate them enough. UIE rounds up the most common mistakes they observe from watching users in testing sessions try to sign in to user accounts.
There are many great business advantages to having users create an account and log into the system. You know who is using your system, how often they visit, and what they do on the site. You can store information they might need later, such as their order history and their billing info for future purchases. And, you can offer them content and services reserved for only your best clientele.
Yet, in usability test after usability test, we see the registration and sign-in processes to be consistently problematic. It's the most common thing that scares users away from shopping on e-commerce sites. It generates the most calls to the customer-support call center
Here's the list of mistakes.
- Having a Sign-in In The First Place
- Requiring Sign-in Too Soon
- Not Stating the Benefits to Registering
- Hiding the Sign-In Button
- Not Making "Create New Account" or "Forgot Your Password" a Button or Link
- Not Providing Sign-in Opportunities at Key Locations
- Asking for Too Much Information When Registering
- Not Telling Users How You'll Use Their Information
Read the full article for scenarios illustrating these mistakes, and the better practices some companies employ to avoid them.