This is the first test of the State Model for User Interface Development.  We will be creating a simple application, called OrganizeIt!

Again, this post is part of the State Model Development series.

Abstract

The basic idea of the application will be similar to a problem encountered working on CouseTopia.  Consider the idea of there are three different classes of items, say Food, Movies, and Bands.

You will be able to select which class of items you want to view, and then a list will appear showing you just that.  For each item in the list, you will be able to expand it and get some more information.

There will also a labeling system and a favorites system.  For any item in any list, you will be able to label it with any of your custom-created labels.

For this test, the server will only be maintaining the lit of items and their descriptions.  Example requests will be sent to the server, but will not actually cause anything to stick.  To test error handling however, occasional random errors will be sent back!

This test will force me to examine certain issues regarding the State Model.  It will allow me to recognize certain things that need changed, things that I forgot (such as a navigation module, and undos!), and will be a test of whether or not this is a viable model for creating UI’s.

Stage 1: Planning

I threw together the mock layout above in Illustrator real quick to show how I want everything to be laid out.  It’s all a really simple interface, with no bells-and-whistles.  Doing a mock like this might be beneficial for you. I generally always do them, at least on paper, before I even begin planning in detail.  Individual methods may vary.

Components

The first part of State Model planning is to consider what uiComponents will be needed.  It’s okay if you forget some at this point, because the State Model is designed for modularity.  It’s easy to come back and add more later, as you see fit.  For this application, I will start with:

Navigation : the navigation in the top-right.

NavItem : the individual items in the navigation, which can be selected.

LabelList : the list of all available labels

Label : an individual label to appear in the LabelList

TabSet : a set of tabs to display the different categories/labels on a page.

Tab : an individual tab, which can be selected.

ResultList : a list of results of items for a given search (or more specifically, category choice/label/favorites)

ResultItem : a single row in the ResultList, might contain more information

Navigations

One of the things I realized I forgot to create is the navigation module.  So I went ahead and put together a simple place-holder module navigation.js.  This module doesn’t handle the back button the way I’d like it to eventually, but that’s an eventual improvement.  When I develop this module further, I will explain it further.

There will only be three navigations involved in the OrganizeIt application, View Items, View Labels, and View Favorites.  I considered whether or not selecting a certain category or label should be a navigation or an action, and decided it should be an action.  Someone else might have wanted to call it a navigation, but that’s just my design decision.  What these navigations show is pretty simple.

Whenever a navigation is activated, it simply changes from black to red.  That’s all.

Actions

There will be several available actions:

addLabel : add a new label.  Show a text box requesting a name, set a color.  No server call.

doAddLabel : confirm label creation.  Send request to server to notify of label creation.

removeLabel : delete a label.  Not in mock layout, so we need to find some way to display this.  Display confirmation box.  No server call.

doRemoveLabel : actually delete the label. Send request to server to notify.

labelItem : label an item with any given label.  Send request to server to notify.

unlabelItem : remove an item’s label.  Send request to server to notify.

favorite : mark an item as a favorite.  Send request to server to notify.

unfavorite : remove favorite mark.  Send request to server to notify.

query : send a query to the server for a new list of items.

expand : get more info about a given item.

Data Model

There will be a piece of data storing the list of labels, by some incremental id.

For each label, there will be a piece of data, storing information like name, color, and a list of item ids for which the label applies.

Similarly, there will be a piece of data storing the item ids that have been favorited.

For each item category query, we can cache the result list with a piece of data storing the query results.

For each item with a given id, we can store all kinds of info like name, moreInfo, labels, and inFavorites.

Issues to Deal With:

It’s always good to consider some possible issues.  Figuring out how to deal with them, when you get there, is up to you.

What if someone deletes a label while they’re viewing it?

What if someone removes a label/favorite while viewing the labels/favorites?

Possible Modification to the State Model

After this excercise, I have recognized that some changes may need to be made to the state model.

1. Navigation back button support should be implemented.
2. A lot of actions had two parts, maybe this should all be implemented in the action object.  For instance, some kind of a confirm call-back.
3. I should work on some standardized vocabulary for discussing the plans.  For instance, Data Model was very confusing.

That’s about it for the planning phase.  Stay tuned for the next step!

---

related post