Category: Usability

Redesigning the “Sign Up Team” Form at pwned.no

I’ve spent a couple of days on and off redesigning the “sign up a team” at my tournament site, pwned.no. The currently live form is divided into two sections, depending on wether you want to sign up one of your existing teams or want to just sign up a temporarily created team — or one you haven’t created a proper team for yet:

Old signup form at pwned.no

I’m not happy about the fact that the form is actually divided into two parts, meaning that you have to read two sections to actually understand that you can sign up with an existing team – or write the name of one right there. The forms also have information that are common for both forms, so we’re duplicating a few user interface elements.

The new form still lack a bit of functionality to dynamically enable and disable the submit button based on the selection in the form, but since disabling the form made it look uglier than ugly, I haven’t added that bit yet. The screenshots also differs a bit since Opera and Firefox doesn’t quite agree on the double border CSS.

The new, complete version:

pwned-signup-new

And if you don’t have any existing teams (clans) available, the form now includes a link to the page where you can create one – and try to explains why you should do that.

pwned-signup-no-clans

Also, if you’re not logged in, you’re just presented with the simple form. I think I’m going to add a notice about signing in with a bit of text in the same gist as the create clan bit.

pwned-signup-not-admin

Hopefully this will help reduce any confusion, but luckily the form is quite small anyways. I’ve also added more proper error hilighting, both before signing up and after failing to do so for any reason. Small fixes, but they should increase usability.

Any suggestions of potential ways to enhance this form even more would of course be appreciated!

First Impression of the WordPress 2.7 Wireframes

I’ve done a few posts about WordPress Usability Issues before (and the original wordpress usability post..), documenting my experiences with starting to use WordPress from scratch. I still manage to publish loads of posts without tags and categories, so I’ve been eager to find out if there is anything in the new version of WordPress that will solve this issue for me.

Then a couple of days ago an article appeared on wordpress.org containing a collection of wireframes for how the layout in WordPress 2.7 is currently planned. Sadly enough, it seems to place the tags and categories part of the layout to a location which is even harder to notice: Below the items in the sidebar at the right. I just discovered that I have a “Shortcuts” and “Related” menu items there, so I’m quite sure that this will be a place that’ll leave me missing the tags and categories even more often than today.

If the placement is set in stone, I’d strongly suggest adding some kind of visual hint to the Save/Publish buttons that indicate that tags and categories are missing; at least if you’ve enabled an option in the settings part of wordpress. It seems as the boxes are draggable in the wireframes, but for fresh users, this will still be confusing.

I guess most people at least want to add a category for their posts, but the wordpress guys probably have a lot of usage statistics on this from wordpress.com. It’d be very interesting to see any change in the usage of tags and categories between the different layouts, and the number of edits that simply add tags and categories within the first 24 hours after a post has been published.

(and yey! I remembered tags/categories on this one.)

Resolutions Be Gone!

(Haha! Thanks to the wonderful internet, I’m on vacation .. and still posting things in my blog .. that I wrote BEFORE we left! How’s that for TIME TRAVEL???)

We should really stop using the resolution information in our statistics scripts for anything. It’s nothing other than curiousity, and it should never be used for making any decisions regarding how a page should be structured. Most people probably stopped reading halfway through and thought that I’m going completely nutters. What do you mean? But .. how can we know how many pixels we can use for our design?

You’re out of luck! Hopefully I’m not singing Lady Madonna and strolling around somewhere in Europe wearing a pink tubetop just yet, and I still have my sanity. Instead of basing our decisions on resolution, we should start paying more attention to actual browser window size. This is interesting from a usability perspective, as it considers the size that we actually can use without demanding that our users start resizing their active browsing window. The desktops I use actively are usually running in 1920×1200, but my browser window is considerably smaller. If a page suddenly would require me to use 1920×1200, I’d be annoyed (and yes, that includes those of you who still think your content is SOOOOO important you should open up windows in fullscreen mode, and still only use 50% of it for content..), even though I actually have a resolution that supports that kind of content.

Since this means that we’d see a lot more sizes than the regular 1024×768, 1280×1024, etc, we’d simply create intervals of “acceptable sizes” instead. We’d have (640-800), (801-980), (981-1099) instead, and we’d be able to give an estimate of how much content we could actually show a certain percentage of our users within their first view of our information. Even though people have 1024×768 as their resolution, we have no idea about how much content they actually see. I have no idea if that means that the majority of people see 500 pixels of content, 300 pixels of content, etc (and that would of course also change based on font size, but .. stay on track with me here), which is actually the useful information to base your decisions on.

So, anyone with me? How about support for this metric in Google Analytics? Anyone know of any existing statistics project that has added support for the actual viewport instead of the screen resolution?

Followup on WordPress Usability Issues

I’ve now spent a fair amount of time with WordPress since I ported my blog over to it from Serendipity. My first experiences were collected in my post titled WordPress Usability Issues, and I’ll further extend on this here.

  • I’ve gotten used to having the “Save”-button on the right side, but this comes from having to learn the location by hand. I still move to the bottom of the page from time to time, but I’m not lost like I were earlier.
  • The location of the “Save”-button has however trigged another problem: since I now move my focus to the right of the page when I’m done writing my post, 9 of 10 times I fail to give my posts any tags or assign any categories to it. This is done beneath the text of the post, but since I no longer move vertically to progress from the post field (my eyes now move horizontally to the save/publish button instead), I never think about adding those. Guess I’ll have to learn that too, instead of following the flow of the application.
  • “Preview this Post” does not save the post before showing the preview. That means I’ll have to press Save, then “Preview this Post”, even though “Preview this post” is placed all by itself and seem to function independent of the other buttons.
  • Not a usability-issue, but probably a simple bug: some times my posts does not allow for comments, and I’ll have to enable them manually by going to the details of the post. I’m pretty sure that I’m not turning them off by accident, as the option is buried even further down from the tags and categories that I’m already having trouble finding without thinking explicitly about it.

Video Browsing By Direct Manipulation

Just got pasted a link about this very neat way to navigate through videos and their playback, Video Browsing By Direct Manipulation. Haven’t read the paper yet (it’s linked on the same page) but it seems that they’re recognizing objects through several frames, and then allow a user to navigate through the video by following those movements. The video says it all.