Résumé XML: Current and Future Steps

I have finished reformatting my résumé into my own XML schema and instance – basically, I now have a formalized definition for what the XML containing my résumé should look like alongside the actual data (in XML format, of course).  The first step was to create what’s called a transform – basically a method of translating the XML data into something more human-readable – so that it can be displayed on my web site in HTML format.  The PHP file that my résumé link points to now actually dynamically creates this HTML display based on the current state of the XML data behind it, so it’s as accurate as the information behind it.

My end goal is to make it so that the XML data drives all presentations of my résumé, including HTML, PDF, Word 2007, and plain text.  While the XML version will always be a complete reflection of my work history, accomplishments, etc. (so things will never be removed, only added), the Word, PDF, and plain text versions will be specifically targeted and abbreviated versions of the information on the site.  The HTML version, on the other hand, is likely to remain a complete transform of the XML (assuming that I don’t end up with so much data as to make this impractical to display properly).

There’s still quite a bit I need to do, though, in order to make this happen:

  1. Create a plain text transform.
  2. Figure out how to write a transform that allows me to create Word documents that have the same layout as my current Word document.
  3. Ditto for PDF.
  4. Modify the original schema (the formalized structural definition of the data) to include targeting parameters so that I can specify which information makes it into which transform.
  5. Add the ability to specify skills/objectives.

Numbers two and three are not insignificant tasks (the last two aren’t either, but require far less effort).  I’m hoping to get this done fairly quickly, since currently, I’m maintaining two copies of the same data in different formats (one in XML and one in Word 2007 format).

Moodle UI hacking

I’ve been doing my own little bit of user interface hacking on Moodle for work, since the layout we had before (below) didn’t work well for our purposes; specifically, the issue we had was with the “Enrolment (remote) database fields” section, which is supposed to map values from a remote database tables into Moodle’s local database tables so that students can be automatically enrolled in courses.  Before, the screen looked like this:

moodle-externaldb-before

My user interface tweaks below include a new mapping category done by our in-house web developer Lucian DiPeso so that the full name of the course could also be used locally.  The new section, relabelled “Data Mapping”, has eight text fields instead of the original six for precisely this reason.

moodle-externaldb-after

The only issue with this layout change is that the help text on the right-hand side of the new table isn’t in line with the rest of the help text on the screen, which I expect to correct soon.

There is one other change that we will be implementing on this screen, but that won’t generate as substantial a user interface change as our need to re-envision the data mapping portion did.

We do intend to commit these changes back to the Moodle core, but we’ll see whether they are accepted or not (this won’t be done until we’re absolutely sure the code changes required across several Moodle files are completed).

Shared Blog Conversations

As some of you are probably aware, Sean Rees and I are both co-founders of Energy Soapbox, a web site dedicated to promoting sustainability and environmental awareness. This blog features posts that focus on diverse issues from the meaning of sustainability to sheepwalking (though I have slowly become the sole contributor as late).

With Dennis McDonald’s post on creating blog-based microcommunities, I actually wonder if we might have approached the Energy Soapbox project the wrong way. In a nutshell, McDonald has been working with another blogger to have a shared conversation posted on both their blogs. They then combine their RSS feeds on the topic and present them as a single page (with each blogger having his own copy of that page on their web site).  Would this have been a better approach for Sean and I to use – establish a common tag or category that would synthesize all of our posts together?  That’s not to say we couldn’t also use the Energy Soapbox domain for its current purpose of displaying a running record of the conversation, but the sort of split McDonald describes would denote the ownership of the ideas better and empathize that Energy Soapbox is merely an additional platform (or – ahem – an additional soapbox).

That said, there is still an important question here – when is it better to “spin off” these sorts of projects into their own space, rather than attempting to combine disparate resources to represent a conversation?  There aren’t any real criteria that answer this question, and that may well be for the best, but this still seems like an important conversation to have overall.

Judging the Complexity of Processes

I’ve been downloading and installing various pieces of software lately, particularly in connection with my work for INFO 498.  One of those pieces of software, oXygen XML Editor, requires a 30-day trial key, and getting that key requires a form to be completed.  I want to demonstrate what’s horribly wrong with the image below:

videodemo

The problem?  The “watch this video demonstration” link.  Why is this a problem?

  1. If your registration process is so difficult as to require a video, your registration process needs to be rethought badly.
  2. Why the video is required is not obvious; the registration process on the web page itself is self-explanatory, since it’s just completing the form and pressing “Submit”.

But wait – what does the video cover?  If you watch it, it walks you through two different forms of registration – via the program itself and via the program’s web site.  Both registration forms to request the e-mail are very, very easy.  The hard part (well – more like “the confusing part”) of the registration actually comes after you complete the e-mail; there are nine lines of e-mailed text to copy and paste into a licensing dialog.  Why nine lines?  Why not one?

  • They failed to consider their audience.  This is an XML editor geared towards developers.  If developers don’t know how to complete a registration form and copy/paste into a text box, we’re all in serious, serious trouble.
  • They failed to simplify their information entry process.  Why the hell do we need nine lines of licensing information to paste into the program?
  • The video restates the same facts twice.  It presents registering via the program and then entering the registration information into the dialog box provided with the application, then presents it via the web site and doing exactly the same process with the application.  There’s no difference between the two methods other than the point of initiation of the request for the trial license.

What did they do right?

  • At least with the online form, they marked required fields.
  • They left the default value of the “Please send me news about upgrades, discounts and special promotions” checkbox unchecked.
  • They only asked for what they needed.  They didn’t request your mailing address, birthdate, or any of the other extraneous information that can make people suspicious of a company’s true intent with the information you provide when registering.

Steve Krug at Adobe Seattle

I had the pleasure of hearing Steve Krug, author of the book Don’t Make Me Think: A Common Sense Approach to Web Usability, at the Puget Sound SIGCHI meeting on the 25th. This is a great little book that’s been on my bookshelf for a while. Steve’s a great speaker and a deep thinker about the subject of web usability, so it was an interesting talk. Some of his key points:

  • There are two things that every designer overlooks: “You are here” indicators and page titles.
  • “You are here” indicators need to be louder than you think they need to be in order to grab attention. These can be in the form of tabs that are shaded to match the page background (he uses StumbleUpon as an excellent example), or in any other format that makes the indicator “pop”. Steve has a confessed bias towards tabs, though.
  • There needs to be a top-level “Home” option – simply having the logo link back to the home page isn’t enough. This is so that it’s easily locatable and so that people always know where they are in relation to the main page. If you use subnavigation under category tabs, center the subnavigation under the tab.
  • Prominent, well-placed page titles are a must. Steve says that “if I look at a page from 50 feet away, I should be able to guess the content of the page”. This doesn’t mean that it has to be the biggest word or even the boldest word on the page. Rather, it means that the page title needs to be well-placed at the top of the content space. It should take advantage of its prominence and its location on the page. He offers up the idea that WYCIWYG (what you click is what you get): in other words, if you click on the link, the page title and the text of the link should convey the same idea. This doesn’t mean that a link named “Contact Us” links to a page with the same title; you could use a variant such as “Get in Touch With Us”, so long as the main idea is conveyed.
  • “So Steve wants all sites to look the same?” No. There are exceptions to these rules (entertainment sites and sites that are meant to be puzzling, to name a couple).
  • The best piece of advice I’ve heard in a while: if something on a web page doesn’t work for a group of people using the site, that’s not an indicator that you have to scrap the design and start over. Steve is a big advocate for making the smallest tweak possible that makes the site more usable.

New Blog Template!

I’ve launched my new blog template, as promised. Hopefully, it works well – if you notice anything, please do shoot me an e-mail (with screenshot and browser/OS information, if possible) so that I can fix it. I ran it through browsershots.org and was fairly satisfied with the results, but it hasn’t yet been tested on a Mac.

Some credit is due here – thanks to the following resources:

I’m hoping this redesign makes everything much more consistent.

Blog Postings with Postie

I’m now using the Postie plugin to post to this blog by mail. I had to modify it, though, since it handles colons (:) in mail subjects in a fairly counterintuitive way: by assigning everything before the colon as the post category. Since it also supports the ability to specify category names in brackets ([SharePoint 2007], for instance, to post to that category), this meant that the colon processing incorrectly dropped that information. Thus, I had to edit the postie-functions.php file and comment out lines 1507-1510, which control how colons are processed.

It seems to work fairly well, though plain text e-mails with breaks post weirdly. This post is testing the HTML formatting abilities, which should work perfectly.

QuickPlanner

After a couple hours of tweaking, I give you my somewhat elegant hacking of the Trip Planner application, produced here in PHP. Not the prettiest code, and I’m sure there’s several security holes, but it works. I’m going to try it out on my Blackberry when I get the chance.

Update: <bait> I’m now wondering what Sean would say. </bait>