From what I gather, a wireframe is just that a wire-frame. It should purely consist of a layout, with the possibility of some actual production CSS in the page. The articles suggested that there are two main ways to do this:

1. Create a page for each "flow" of your application.
2. Create one page with a "stacked flow" of your application.

Basically, a flow is the various screens/interfaces that the end-user will be presented with. They give a nice "login" example (one which I actually made one of my own as well) with a "stacked flow" wireframe. You can see my example of that here. Comments are welcome, but keep in mind:

1. I'm not a graphic designer
2. This is my first crack at this
3. It's 2am... and I'm making wireframes...

Needless to say, that's kind of how I feel at the moment. The actual prototype, which I plan on using YUI for will probably come out tomorrow or sometime next week.

The reason I actually went through and made a wireframe, is because I'm attempting to get some sort of side project going for myself (yet again...) so I can play around with some new things. These things being YUI; as mentioned above, Python; which I've been somewhat getting into and web frameworks - namely Pylons. So tonight at least I got some wireframes done for the login, the next step will be to learn some YUI and get some fake data going for the prototype.

Lastly, I (possibly re)learned some interesting things today regarding CSS. As you can see in the source for my wireframes, I'm actually using display: table. Insane! I've never actually used that, ever. I initially had a pretty descent layout, but when looking at it on my Nokia N800, it looked completely borked! So the only way was to make div's within my login box actually span set percentage widths.

Now you're probably saying, whoa! Just set a width on that puppy and your good to go. Wrong! Since I wanted somewhat "tabular" data, consisting of two rows, and two colums. Each row being 100% the width of the box and each column being 50% of the row, there was no way to do that using pure css and not using tables. This is for two reasons:

1. Div elements are initially set as display: block. This means there is a line break before and after the element. So there's no way to have two "columns" side by side.
2. Inline elements (or elements set to display:inline!) do line up side by side; however!, they will only take on as much width as they need, and don't respond to width: styles. They may use the width attribute in some browsers, but not what I was testing it in (FireFox 2).

So I came across an article talking about using display: table. And really, it couldn't be simpler. Parent element needs to be set as display: table. The children of that needs to be set as display: table-row. And the children of the rows need to be set to display: table-cell. The only downside, is there is absolutely no support for colspan or rowspan in css or the markup. Even if they did work, it looks like the CSS for those will be depricated in CSS 3 and replaced by some other multi-row/column attribute.

So all in all, a night of learning pylons, which I'm really starting to like. And hopefully I'll keep cranking out these wireframes/prototypes and get good enough at them so I can actually use them in my daily work. And although I'm posting more now... I hope I don't make a habit of posting at 2:30am : (. Next time I'll hopefully have some stuff on prototypes to discuss.

\

Awesome 90's cartoons aside, there are things that we can learn from the user! The past few weeks I've been re-desiging a lot of the web user interfaces here at work. I've found that when I'm given a chance to update an already designed UI, I can pretty much copy the old style and just give it a "web 2.0" boost and add in some new functionality - no biggie. But when given a completely new projectthat is done from scratch, I start to get a bit lost.

The reason I bring this up is because last sprint I was given a chance to make a new web tool for some of our in-house support staff to use. This tool replaces some minor SQL query's that I would do on a day to day basis, so I was already pretty familiar with the project. Initially I threw together what I thought to be an all-in-one awesome bone-crushing tool that did everything it had to... and more! However! Upon dropping this tool on our support staff, it became readily apparent that they were not terribly familiar with all aspects of this particular system, and had no idea how to use my brand new shiny tool. Oops! Looks like my user interface doesn't fit the job!

In all fairness it is completely my fault, because I was trying to make a tool that I would use, and not a tool that your average Joe User would use. So after going over my UI with some of the people that were actually using it, I got some input and tried to see if I could possibly improve upon my abomination of a webpage. Now here's where I get into my UI design. I assume everyone has pretty much heard all of these before, but this seemed to really hit home for me this past week - so I'm putting them up anyways!

Simplicity! You'll hear this time and time again about making things easier for the user. And most of the time, they're probably going to be right. My first iteration had a real classy whiz-bang multiple selection drag and drop interface, when this clearly was not even needed in the end-user interface. It was just going to be a new thing to learn, and a new widget full of potential bugs. So that got scrapped and replaced with a table layout using divs. This way the user can just focus on one element at a time, and it makes handling the data immensely easier on the programming side.

Dialogs are also an amazingly easy way to make things simpler. Everyone has seen them, everyone knows how to use them and it's no surprise when one pops up. Using dialogs completely changes how a page can be viewed. Instead of displaying all information all the time, just display a lot of very specific information when a user requests it. This not only makes your layout a lot cleaner, but also allows you to separate functionality from various sections of the page.

Consistency! Granted, with a lot of the new javascript libraries such as dojo an YUI, there are lots of awesome widgets at your disposal. The problem is - is that if the user doesn't know how they're supposed to work, how is that actually helping them? This was pretty apparent with my drag and drop widget that I mentioned above, but simple things like common layouts as well as how the data is presented also have a huge impact on how well the UI is received. So in keeping with the above comment, simple and consistent seemed to be the way to go.

Quick and Verbose! So obviously with the newly (re)discovered XMLHttpRequest techniques, this gives an opportunity to make people not have to navigate from page to page - like it was 1995. Using XHR's to speed up saving or loading data in the background makes pages appear to be loading faster as well as makes the user happy. Win-Win! The only problem is - is that you still need to let the user know what's going on. In most cases a simple throbber will do. So along with the verboseness, some helpful messages are always nice as well. If creating a pdf is going to take a few minutes on the server, maybe you should let the user know that. This way, hopefully, they'll think twice before actually calling in and complaining about how your site is slow.

So all in all, I cranked out my re-designed tool over the weekend and Monday morning it was getting put to use. Everyone that's using it seems to be a lot happier and more comfortable with the tool, which makes me a lot happier because now I no longer have to be diving through SQL to make minor changes. Obviously no UI is going to satisfy everyone, but following the above will at least get me started on the right track from now on. I also find myself drawing about 10 to 15 drafts of what I think the wire-frame should look like before I even start coding. This is a pretty big step from where I was 2 years ago and so far it seems to be working well.

I apologize for the lazyness in posting, but I have been somewhat busy between work, side projects and other things. So hopefully I can get back into the habit of posting.