WordPy and the Linear User Interface

One of the reasons for the complaints about the user interface for the Internet Tablet is that it is not linear enough. If you will, programs are designed to solve a problem, but have many side roads exposed to the user when they are on the way to solving the problem. And in some cases, the program is designed to solve a problem, however the application was designed so simply that the only indication that the program solves a problem for the user is in contained in the name of the program.

There is not one solution for this kind of user interface convention, but I do want to highlight a development effort underway with the WordPy blogging application where in its move to increase functionality that a different user interface paradigm was employed. In a draft version of the next iteration of WordPy, this concept of progressive, linear exposure of features demonstrates how Internet Tablet applications can contain the power of a full-sized PC application, but be maximized for the smaller screen and different interface.

The Current Version of WordPy

WordPy is a blogging application for the Internet Tablet. Its designed for use with Blogger and WordPress blogs and after a recent refresh, has been made compatable with the IT2007 operating system, and both Chinook and Diablo editions of IT2008 operating system.

Its main aspect of interaction happens through tabs. These tabs contain the instructions for main editing text, advanced options such as extended entries and tags, and a preview post component that allows one to see the post before hitting publish from the IT.

Settings are managed via a modified (from the default Maemo style) system menu. One can link to Flickr and Pisca web albums and then add pictures from those albums to a post. There’s also a post delete function that enables on to delete any previously published post.

Seemingly simple and to the point. But there are some interface problems with that version of WordPy that at first glance don’t seem like a major issue, but in the context of the IT and its usage paradigm, are pretty major issues.

Some of the Issues with WordPy

• The title field sits on a second tab, meaning that one has to navigate to another screen before publishing even the simplest of posts.
• Advanced features while present clog up the third tab, leaving little room for anything more unless a new tab is added
• The preview tab shows the post, but not using the style sheet of the blog, nor does that preview screen allow the user to post from that preview screen
• Additional settings sit a few levels deep in the Publishing menu

There are other issues that can be detailed and we will not go through them all here as its beyond the scope of the view. I believe that there is another way to interact with applications on the IT that are more conductive to simply getting things done. And to do this, by progressivly opening functionality as the user goes through the application, makes for a more pleasing experience, and overall a shorter time from idea in head to post on the page.

An Initial Proposal

Initial WordPy UX/UI Proposal

As you can see with the screenshot (larger view is linked to my Flickr), compared to the latest release of WordPy, this proposal seeks to minimize the amount of dialogue boxes so that on a 4in screen, the user can be more concerned with the content and less about the other things that they cannot do.

If you are one who is into methodology, the idea behind this proposal was to unfold features as the user dug more into the program. To allow for exploration to open more features without exposing all of those features all at once, creating a powerful yet intimidating interface.

With tabbed interfaces, you can assume that just because the user doesn’t see it that they aren’t wary of more features. But tabs invite touching, and as Amazon learned when their site got too large for the 40+ sections of their website, there can be too much to touch when too many functions are added. By using a methodlogy of progressive, linear screens, an application like WordPy would be able to take advantage of the current feature set, and then also have additional functionality grafted on without changing the core user experience.

A View of the New WordPy

WordPy Future (link points to .deb file) is the current UI/UX preview for the new WordPy interface.

As one can see (screenshots coming soon, hopefully), the interface relies not on dialogue boxes, but screens. From simple information screens such as the post, add image, tags, and preferences screens, to simpler effects such as making it easier to edit or delete a post by just clicking a button from the application home screen; WordPy is designed for a device that has a smaller viewport than a PC, and accepts different interface options than a keyboard and mouse.

Following along the UI/UX screenshot posted above, the point of the interaction is not on the features, which are clearly here and in more abundance (viewable) than the current version, but on posting. With any program, the goal isn’t just to have features, but to solve an issue first, and let the features be revealed to the user as they are needed.

This is a linear user interface. Meaning that you start at one point and then move to another with end-points to a final product, but very few side-streets from the main task. If a person opens WordPy and just wants to post and go, they open the application, hit Create Post and then just write and hit publish. Those that want more functionality can expose it by clicking on successive buttons which expose more functionality. When the application’s feature set has been maximized, the application ends at the same point – Post.

Disclosure

So that you (the reader) do not think that I am coming against the developer of WordPy in a very public arena, this is something that I presented to him many months ago and has now made it to a UI preview stage. At this stage, I felt it appropriate to call to the table the different UI/UX conventions being employed here. But opening the dicussion of this method, it is my hope that developers reading this blog will start to think through how they design applicaitons beyond just the solving of a problem but also taking into account the fact that solving a problem on a PC is not solving a problem on an Internet Tablet.

More Information About WordPy

WordPy has been developed by Daniel Martin Yerga. The current version is compatable with the 2007 version and all versions of the 2008 Maemo Internet Tablet operating system. The version spoken of in this article (WordPy Future) is a future version that is currently under development.

For more information about the current version of WordPy, to contribute feedback or programming assistance, and to download for Nokia Internet Tablet devices, visit the WordPy homepage at Maemo.org.

Advertisement

Addressing the Stylus-Driven UI

Given the fact that touchscreens have become nothing but the “in” thing to do, it seems like most every innovation with the Internet Tablet focuses on making it finger-friendly. Now, there’s nothing wrong with it, and personally I prefer it. But, what would happen if we addressed the UI from a perspective of being optimized for use with a stylus?

Navigation

As much as sometimes we don’t want to admit it, using the stylus is sometimes the most effective way to navigate around the tablet. Here are a few recommendations for making the stylus more effective:

• Making actions such as tap and hold more evident on things like text, icons, and when items are highlighted by showing a star or some kind of indicator that there are some additional functions
• When scrolling web pages and long documents (PDFs, etc.) with the stylus, show trails that accelerate or decelerate scrolling speed as well as FF/RW buttons to do a quick page up/down action on the page
• In applications that feature forward and back, allow for gesture actions with the stylus to go forward and backward (essential in full-screen mode)

If you will, the point here is keeping the stylus in your hand, and a part of the interaction of the tablet that finger-friendly UIs expose.

Writing

I want to break this up into two subsections, handwriting and keyboard.

Handwriting

• In terms of handwriting we can look at having a transparent writing pad appear over writable sections (when the focus cursor is activated for those items)
• Improve the sensitivity of the handwriting engine so that letters that are written together can be easily trained and recognized (maybe some type of AI can be added here)

Virtual Keyboard

• Allow for users to not have to lift the stylus, but at every “stop” and “direction change” the letter is recognized.
• Change the location of the word compted words to the top of the virtual keyboard, keeping the space bar free from being possibly taken up by too long a list of words
• Transparency could be nice here too

Thinking About Different Needs

I know that we normally want to think about things in a way that seems comfortable to us, but the truth of designing a user interface is that you are making something that is comfortable to be learned for someone else. Fingers are great, and painting with them can really amount to some neat artwork. But for those that like to use a brush, attention has to be paid to them too, because some really nice masterpieces can be made when we make sure that the canvas, paints, and brushes have been made with them in mind too.