Ed Tech UI Guy

Monday, January 31, 2005

Links and Validation

We're at the stage in the gradebook project that every UI designer dreads. I need to provide detailed specs on application behavior, so the programmers have a plan to code to. I usually avoid this job - either I work so closely with a programmer that we just do them verbally as he codes, or the HTML mockups are so complete no specs are needed, or someone else does them.

The teams I've worked on call these specifications the "functional specs." The document at the beginning of the project that details what the application will and will not do is the 'scope statement' or 'requirements.' I'm only mentioning this because some teams call that early requirements document the functionals specs. I don't think that document is specific enough to be called 'specs' - I don't think it should be, either.

I've started functional specs for the Gradebook twice. Both times coincided with disruptions of the project, as the programmers realized that Sakai didn't have the framework to support the application yet. This time we moved on by scaling back the project drastically to do what we could with what Sakai currently offers new apps. This scale back meant many fewer screens, and much less to write!

We tried several approaches to writing these specs. By Friday in conversations with the two programmers on the team, Berkeley about what they needed beyond the wireframes, it became clear that 90% of their questions about the wireframes boiled down to initial view, links and validation.

  • Initial view: Who can see this page? Are any elements hidden from some people? What's the default value of the elements, the default sort order of the list? What if nothing has been added yet (e.g the assignment list before any assignments have been added)?
  • Links: What happens when each link or button on the page is clicked? What page comes up on cancel? Any special messages on submit?
  • Validation: Any time there are form inputs, what are the acceptable values? What needs to be checked before the form validates?

When I write up these answers for each page, they can be used with the wireframes as a complete spec. Any other questions that come up I can clarify adding notes to the wireframe itself. This isn't absolutely bullet proof, but as Ray (one of the team members at UCB) said "this isn't IBM." I can get the specs done is a few painless hours, and the programmers can get to work. I feel liberated from the fear of specs.

Wednesday, January 26, 2005

Learning GNU Emacs

I strive every day to be a better nerd. I just got my copy of Learning GNU Emacs, 3rd Edition from O'Reilly so I can start doing my text editing from the terminal. I love watching experienced Emacs users blaze through text files making updates at top speed. Maybe once I've done that I'll start hosting this blog using Bloxsom the nerdiest of all blogging tools.

Tuesday, January 25, 2005

Sakai Class List

You know what I'd want in Sakai before I used it to teach a class? A simple class list tool. The tool would give me page listing all of the students in my class. Here's some more stuff it should do:

  • Let me see their pictures
  • Let me see which ones come from registrar's list
  • Let me add people who aren't on the registrar's list
  • Let me add 'guests' who can lurk in the class without participating
  • Let the students decide whether to share their contact info with eachother
  • Students viewing the page can see themselves plus anyone who's shared their info.

That sounds pretty easy right? It seems like a basic requirement for any learning management system. I'd like it right now so I could see who else is a member of some the groups I'm in. I'll be doing my bit to agitate for it's inclusion.

Friday, January 21, 2005

Releasing on time vs. releasing complete

I spent most of last week at a Sakai summit in Indianapolis, with all of the architects, all the designers and all of the board members. The meeting was pretty rough, but productive. The hard part for me was the realization that we were going to have scale back the functionality of the gradebook I've been working on for the last 6 months, in order to guarantee a release in June.

During a late night meeting in a hotel lobby a group colleagues from MIT and Berkeley cut and cut until we had something that could be delivered even with out some of the Sakai features we'd hoped would be in place to support it. The absence of sectioning and flexible user/group management really cut back on what we could do. But the initial release will satisfy the needs of Indiana and Foothills, the schools that will roll out the gradebook in the Fall.

Despite the difficulty I am happy that we no have a very realistic plan and we're full of confidence that we will succeed. The initial release of the gradebook will be followed by expanded functionality in a couple more, hopefully reaching the full scale app that I designed by the end of the year. This iterative release schedule will let us do more user testing and will ultimately result in a better gradebook.

I think the tools I like best in Stellar have benefitted from having limited functionality in an initial release with improvements based on user feed back every 3-6 months.

Friday, January 14, 2005

OmniGraffle 4

I visited MacWorld today, with Marc Brierly from Stanford. Marc is real good about talking to the vendors. We got talking with the project manager for OmniGraffle about their next release. He gave us a little sneak preview of OmniGraffle, which will be released in 3-4 months, and I was really pleased with what I saw.

I use OmniGraffle mainly for drawing wireframes. The best new feature for that was the Canvas templates. When I'm designing an app I draw each screen on a different canvas in OmniGraffle. The down side, is that the shared navigation elements need to be copied onto each screen. If I decide to change a label in the navigation, I then have to make a change on each screen. The new canvas templates will eliminate that hassle.

Another tiny feature was the ability to torn a single box into a table. I have wasted a lot of times drawing simulated data tables in OmniGraffle, so this is a major improvement for me.

There was more nice stuff (the UI got much cleaner, drawing with Bevels, and more) but those two features alone will save me hours. I can't wait to upgrade.

(You can see my family blog for more MacWorld impressions)

Thursday, January 13, 2005

My CSS Faux Pas

I discovered this morning that I have been doing some of my CSS and XHTML coding wrong. I am chagrined

I've always coded anchor tags so that they are empty, like this:

<h3><a name="Goose"></a>Goose</h3>

Instead of wrapping them around text like this:

<h3><a name="Goose">Goose</a></h3>

I did that because otherwise the the Text in the header would look like a link. And that's because I'd been applying to <a> tags in a sloppy sloppy way. I was applying styles just to 'a' instead of 'a:link.' Here's the right way to do it. I hang my head.

Wednesday, January 12, 2005

XSLT badness

I've going through templates replacing code like this:

<a name="learner"></a>

With this:

<a name="learner">

If I don't do that, the XSLT processor creates an anchor with no closing tag, breaking the layout. I've really lost some respect for XSLT. It's not keeping up with out design techiques - it's been really hard to use XHTML.

Update: To be fair, I shouldn't have been blaming XSLT, I should have been blaming the outdated version Xalan (the XSLT processor) that we are using. Sorry XSLT, man, it was the stress talking. I still think you're way cool.

Tuesday, January 11, 2005

Samigo and Gradebook sittin' in a tree

We held a meeting between the development teams for the Sakai Gradebook and the Sakai Assessment Manager (aka Samigo). This was pretty easy to arrange since we're all in the bay area now.

We looked at the two apps in some detail and noted the overlaps and potential conflicts. The Samigo project is much farther along, so hopefully our team will benefit from some of the work they've already done.

Here's a diagram Ray Davis sketched on the white board to show the differing scopes of the two applications.

Diagram showing overlap in scope between Samigo and Sakai GB

It shows that Samigo shouldn't worry about final grades and the relationships between gradable objects, while the Gradebook shouldn't worry about how assessments are built and scored. They overlap only where assessments become gradable objects. That looks tiny, but it actually touches a few places in both of our UIs (and has a much bigger impact on back-end programming). Still, it's manageable and tidy.

What we're are doing is is building a little tunnel between modular applications that can exist independently. It's an interesting approach to have a collection of tools that do their own thing well, instead of one big tool that does it all. It's an attractive approach to developers collaborating on an open source project. I wonder if the people using Sakai will appreciate that model, or clamor for tighter integration.

Monday, January 10, 2005


I just spent an hour of precious evening time doing trying to set up Subversion on my Powerbook. I got the client going fine, but setting up the server was another story. The instructions in that article weren't a great help, as they would've turned my Apache2 server into a dedicated subversion server, which I don't want to to do. I know I'm in a bad way when I'm doing terminal commands I don't understand and editing my Apache configuration file, when I really shouldn't be.

I was doing this to have a version history of my ongoing Docwalla wishlist work, which is vaguely useful. I don't don't know why I do these thing where I work on something well outside my nerd-comfort-zone. I'm probably learning something, but I'm also failing.

Friday, January 07, 2005


We've been using Basecamp for the past month to keep track of our projects at AMPS. Mark, the manager for EDDG, has found it very useful for keeping on track of things. I am big fan the UI - I have found very easy to get things done, and I appreciate having RSS feeds for each project so I don't need to check the site.

I think the reason Basecamp has worked well for us is that our team works in a similar way to 37Signals - we focus on the screens, an by the time we're done with them a part-time programmer can get the application backend working fairly quickly. The "The Building of Basecamp" Review on Gadgetopia gives a good peek into the process, and the vibe of the company that built it (sadly, we don't have a a super hip HQ or even a foosball table).

It looks like we are going to use Basecamp at Berkeley to manage the Gradebook project as well. The fact that we could get going with it quickly and the low cost of entry made it an easy decision.

Evolution of Stellar

I updated the chart on the Evolution of Stellar. The look switcher, new xhtml/css looks and the style switcher are our big improvements. Stellar is generally pretty stable though, as you can see by the nuber of black dots. There used to be many more empty dots.

Mirabile visu

There's another new Stellar look, this one by Joanna. She's named it Mirabile. It makes me think of Superman's secret HQ in Antarctica.

Thursday, January 06, 2005

Stellar Lime

Check out the new Lime look Stacy designed for Stellar. I love it.

Wednesday, January 05, 2005

The JSF Bottleneck

New Sakai tools are meant to use JavaServer Faces (JSF) to output the HTML people see when using the tools. We've been using XSLT to do the same thing in Stellar. I'm having some real difficulty with JSF as a user interface designer.

I was initially optimistic about JSF. Using standard Sakai tags to create HTML meant that if everyone uses JSF, it will be fairly easy to standardize UI elements in Sakai. And if we were to change one of those elements, a Java programmer could change the JSF tag. The HTML output would change in all Sakai tools.

But as we approach actual tool developments I've got some real problems with the technology. In JSF the HTML that is rendered is buried in Java code. There are lot's of skilled XHTML/CSS writers in the world, but most of them aren't Java programmers. So as a UI designer, if I want to change the HTML that users see, I need to communicate that to a Java programmer and wait for them to make the change. Using XSLT I could make those changes easily on my own. So by using JSF we've got this really inefficient workflow, where Java programmers, who are usually really busy doing other stuff, are also the gatekeepers for most UI changes.

Compounding the inefficiency, in Sakai we are planning to use a shared library of Sakai JSF tags. That means in order to get the HTML output modified, I need to write up the request and send it to a programmer I've never met, and who is also really busy working a variety of Sakai jobs.

It seems like we need a better way. I'm committed to outputting style guide compliant HTML, but I'm not sure JSF is the way to go.

Monday, January 03, 2005

Programming Language Popularity

The Programming Community Index attempts to calculate trends in Programming Language Popularity month to month. According to the trends Java had a rough year, while PHP had a great year. I'm not sure the methods are really rigorous, but it's interesting to see.

Sunday, January 02, 2005

Romeo - Bluetooth Phone accessory

I've been looking for a little app to to improve communication between my blue tooth cell phone and my powerbook for a while. Romeo looks like it fits the bill. It has a variety of ways to use your cell phone as a remote control. What I like is it can turn on my screen saver when I walk away from my power book, and it will tell me who's calling when my phone rings. I might use the phone to page through presentations as well, so i don't have to stand next to my lap top while I talk. Simple stuff - but it's taken me a while find an app that's free (as in beer) and does it well.