Drawing Inspiration

Today I pulled out a blank sheet of paper and a pencil and started designing a user experience.  Some people might say I'm putting the cart before the horse here, thinking about UI and process flow before I've created a data model or class diagrams.  To those naysayers, I say: nay!  How do you like that?!  

This process is not only an extremely useful lead-in to those other design exercises, but it's also a perfect opportunity to refine our requirements.  Plus, sitting down and imagining what users will actually see (and touch) when they use the app is a great way to get motivated. 

So let's look at what I've got here.

If that's a bit hard to read, you can get the original, full-sized PDF here.  

This drawing helps move the project forward in a number of ways.  

User Experience

For the first time, I'm really thinking in concrete terms about the experience of someone using this app.  I'm focusing on the flow of interaction, but occasionally drilling into the details of individual interfaces.  Already, opportunities for improvement are clear.  As I was drawing, I realized that there are too many steps involved in certain actions.  

When you get down to it, there are only two important features to this whole system:  

• taking attendance
• reviewing past attendance data

Taking attendance is the primary function.  It's got to be dirt simple, fast, and easy.  In this mockup, it's none of those.  Assume an already-populated class of students (big assumption, that) and just count the steps from the home screen:

1. Click(tap) into the app
2. Wait for the UI to come up
3. Scan (or scroll + scan) the table view for the current class
4. Read options menu
5. Tap "Roll Call"
6. Finally arrive at the roll call interface...
7. Scroll through the student list.  
8. For each student...
1. Skip if present (default present)
2. Tap absent students to expand absence controls
1. Tap excused / unexcused
2. Fill in detail message (optional, but very time-consuming)

 Yeah, I'm uninstalling this app -- this is way too slow and tedious.  Happily, I can see several ways to improve this already:

1. Open directly to the roll call page if a class is currently in session.  This requires the instructor to fill in the dates and time of the class, though. 
2. Ditch the "tap to expand" on the student.  Have excused/unexecused options as checkboxes.  Allow them to be unchecked to revert back to present; disallow simultaneous checking.  
3. Auto-expand details text input when an absence condition is checked.  Maybe.  Inputting text is slow; it might be better to provide a button that the user can blow by if desired.  I can prototype a few versions of this.  I want to make it available but unobtrusive.
4. Give a way for students to mark themselves present.  This is a technical challenge, mainly due to the difficulty of preventing fraudulent check-ins.  But if performing roll call is so tedious as to hinder MVP, then it must be addressed.

All that from a few boxes, hasty sketched in two minutes!  Like writing, much of software development should occur before you ever lay hands on a keyboard.  

Simplifying Navigation

Let's look at general navigation for a second. You'll notice this three-option "landing page" after choosing a class.

Class "landing page"

There's an implied navigation controller with the "Back" button there.  Navigation controllers are nice in that they give you a framework for moving through various screens, but they also function very linearly; you push deeper into the "screen stack" with every click.  Jumping back is possible, but -- crucially -- communicating to the user what is happening is a challenge.

Remember the Mental Map

When you use any software, you are constantly constructing a mental map of where you are, and how you arrived there.  It's part of the contract between the UI designer and the user to avoid breaking that model.  If you do break it, you'd better be doing it deliberately and full understanding of the consequences.

The problem with this navigation controller-centric UI is not only that it requires too many clicks, but it also simply makes that mental model unwieldy.  It's just a long line of screens.  It's non-trivial to get from, say, entering a new student to reviewing past class history.  We need another model.  

That's why I later went back and scribbled this little fella at the bottom of the first screen:

Tab Bar, not be confused with a Bar Tab

That's another standard iOS navigation conceit:  the Tab Bar Controller.  It has the advantage of always keeping the core areas of functionality visible and accessible.  No backtracking to get where you want; just jump from the tab bar.  I'm not sure what goes under the gear; it can probably be replaced with something more useful, like maybe... taking you to the roll call for the current class.

No More Landing Page

With the tab bar, I can get rid of the "landing page" above, but that prompts a few more questions.  

1. Editing the roster.  If there's no explicit link, then what?  I think editing the roster can be integrated into the roll call table view.  It already has "add student," so an Edit mode (another common table view feature) could be feasible. 
2. When does the user take roll?  What happens if the user wants to enter data in advance or after the fact? What if they open the roll call screen during a time when it's ambiguous what date should be saved?

It's starting to seem like we might need, at minimum, an option to change the current date of the roll call data.  

There's plenty more that can and will be said about the UI design -- I haven't even talked about reports yet -- but I'll save that for later.  For now, let's look at what non-UX information we can glean from this exercise.

Identifying Key Classes

From a survey of these two pieces of paper, it's obvious what many of the view controllers and custom views will be.  We'll have two table views (UITableViewController):

• a course selection table view
• a student selection table view

The contents of these tables will vary.  My drawing shows a main course selection table, and then a differently-styled course selection in cases where you need to filter a student report to a single class.  I can probably unify these styles, and even if I don't, they can use the same controller.  

These tables will contain some custom cell types:

• student cell that, depending on context, includes...
• details on past attendance
• an info button that leads to the student edit screen
• controls for marking a student absent / unexcused / excused with details
• course cell that shows class participation as a ratio or percent, maybe with a nice color or mini pie chart background

and two input forms:

• student create/edit
• course create/edit

other views include:

• a calendar view that is customized to highlight certain dates

There may also be some sort of graphing need, although that's not part of MVP.  I can keep an eye out for good plugins for that.  These classes will be good to keep in mind as we start thinking about software design.

Data Implications

Making a diagram like this can also give some insight into how your data model should behave.  For instance, it wasn't until I drew the UI for adding a student to a class roster that I realized you should be able to "add existing."  This implies that students should exist independently of courses so their records can be reused later (whether because you accidentally removed them, or because a former student is taking another class of yours).  I'll talk more about the data model and persistence strategies in a future post.

Prototyping Tools

Before I finish, I'd like to recommend a few alternatives to the freehand drawing method I used today.  For iOS-centric UI design, there's an excellent app called Blueprint.  It's a bit pricey at $20, but it's a professional tool that lets you mock up iOS interfaces, interact with them, tweak them, and repeat.  It's a great way to get iterative with your design before committing to code.

Another cool option is POP: Prototyping on Paper.  I saw some students use this at a hack-a-thon a while back.  It lets you draw pictures like I did above, then capture those images and make them interactive.  It's definitely an eye-catching, engaging way to show off an idea.

Find Test Users

Both of these tools give you the ability to prototype and test your UI.  It's fantastically useful to be able to hand your concept interface to real people and watch them use it.  I was able to come up with many improvements to my design by just imagining myself using it.  Just think how much better the feedback will be when you get it from other people!  

That's enough for now!