tdog.blog

Wow, in just 33 hours (give or take), we’ll be starting over with a brand new year. It’s gonna be 2004–hard to believe. I’m a big science fiction fan, so of course I’m a little disappointed that here we are, hanging out in the future sans any of those cool personal jet packs, daily ferries to the moon, and little shark fins on cars (although the VW Jetta has a very sharky looking antenna on top of it).

One thing is for certain, though, the Web is racing into the future just about as fast as it can. Now that all the hype and market focus is looking elsewhere, the family of technologies that comprise the Internet are starting to make a difference for companies of all sizes. Many folks who haven’t been paying attention to what’s been happening will be mightily surprised at the ways we’re saving money, time, energy, and everything else with this peculiar medium.

So here’s my first annual attempt to prognosticate the future–and yes, next December, I’ll revisit some of what I’ve said now to see how right (and wrong) I was.

1. Most of the effort put into the Web during its first 10 years of development focused on publishing information for human consumption. There are millions of web sites out there providing all kinds of information in every conceivable info-niche, but hardly any of it is structured in any way.

This lack of structure makes it very hard for computer processes to communicate with each other–after all, computers don’t have our ability to make wild guesses at what this number or that string of letters means. The next few years will see an increasing focus toward structured documents (such as XML) to make it possible for computers and computing processes to interact more efficiently. We’ve already begun to see this happening with Web Services, and companies all over the world are starting to realize that millions and billions of dollars in savings are possible from such efficiency.

2. Because sharing information was the primary focus of the Web in its early years, a great deal of technology arose to meet that focus–namely, content management systems and tools that made it easier to create Web content. In the coming year, sharing computing resources will start to take on more and more importance. Grid computing, already fairly active in the academic and research worlds, will finally feel the benefits of emerging open standards. Companies of all sizes, and eventually consumers, will have access to affordable supercomputing horsepower. If we can figure out how to monitor it, secure it, and charge for it. In the meantime, there’s still plenty to do with Web Services.

3. If COMDEX 2003 showed me anything, it was that the desktop PC is long gone as the sole viewing platform for Web content. Smart phones–capable of surfing the web, fetching email, and working as a PDA–finally have the right size screens. Tablet PCs–light, ergonomic, and powerful–finally have enough oomph and pen computing smarts to help around the office. My friend Barbary Brunner of Microsoft showed me her SPOT watch (that’s Smart Personal Objects Technology). It’s basically a wristwatch that gets news feeds, stock tickers, weather, and oh yeah, the time from Web sources. In the future, Microsoft is planning on adding lots of other content streams as well.

What do these three trends spell for Web development consultants? For one thing, we’re going to have to design for a lot more viewing platforms besides IE and Netscape. We’ll have to structure more of our content as XML or database content and then transform it into the appropriate formats. And we’re going to have to think beyond the needs of content publishing and examine other ways that Web technologies (such as extranets and Web Services) can save our clients money.

I’m looking forward to 2004–the Web has come a long way in the past 10 years, and finally we’re starting to see the kinds of stable technologies (XML, mobile devices, etc.) that will allow the Web to leap beyond our expectations.

Comments(0)

Without XPath, you really can’t control XSLT (and other XML technologies) with any kind of granularity. To draw an analogy, working with XML technologies without a knowledge of XPath is like trying to understand databases without knowing SQL.

Just like SQL, XPath is a query language, but its syntax is more closely related, in some ways, to regular expressions. At the same time, it’s also a syntax that defines structural parts of an XML document in notation that is similar to file paths.

For example, if you were working on a UNIX machine and I told you to open up the following file, you’d know to look in your current working directory:

File.xml

However, if I told you to look in:

../File.xml

You’d know to look in the directory “above” your current working directory.  Similarly, if I told you to look in:

/home/File.xml

You’d go all the way to the root of your directory hierarchy and then look in the /home directory for the appropriate file. We all know, instinctively that these three file path notations could be pointing to the same file or to three completely different files, depending on our current working directory.

XPath works in much the same way. You can always grab the root element of a document like this:

<xsl:template match="/">

With XPath, you could match all elements that share the same name:

<xsl:template match="//title">

Or you could match only certain elements, depending on their context within an XML file:

<xsl:template match="memo/title"> 

<!—- only grabs title elements belonging to a memo  element -->

You can retrieve elements using the “.” and “..” notation as well. Predictably, “.” is shorthand for “the current node” and “..” is shorthand for “nodes that are children of this node’s grandparent”.

If XPath were just good at retrieving nodes based on a path, that would be terrific. However, XPath also allows us to be more discriminating with our searches. For example, we may want to retrieve only those elements that have a certain attribute value set:

<xsl:template match="title[@priority=’hot’]"> 

<!-- only grabs title elements that have a priority  value of hot -->

The @ symbol in front of priority designates that we are searching on an attribute value. What if you want to retrieve all title nodes that have any priority value set:

<xsl:template match="title[@priority]"> 

You can even mix and match. Here’s how you pick out all the date children nodes of title nodes with a hot priority attribute:

<xsl:template match="//title[@priority=’hot’]/date"> 

Notice that you can also use similar notation to find those elements that have a certain value. For example, let’s say that in a slightly different schema, we are storing priority values in XML elements, not attributes. If we want to retrieve all the title elements that have a priority element set to hot, here’s how we’d do it:

<xsl:template match="//title[priority=’hot’] "> 

All we have to do is drop off the @ symbol and we can work with the value as stored in an XML element.

Here’s how you retrieve the first and last nodes in a group:

<xsl:template match="memo/title[first()]"> 

<xsl:template match="memo/title[last()]"> 

You could also select the first node with:

<xsl:template match="memo/title[1]"> 

Or even:

<xsl:template match="memo/title[position() = 1]"> 

In other cases, you might need to select multiple branches in the same document. For example, here’s how you might pick out memo titles and authors at the same time:

<xsl:template match="memo/title | memo/author"> 

You could, of course, select all nodes in a certain context with *:

<xsl:template match="memo/*"> 

As you can see, the XPath query language is powerful and flexible—it allows you to retrieve just about any combination of nodes you need, and that can make all the difference when you’re working with XSLT and other XML technologies.

Comments(0)

Customer: Spinal Concepts
Problem: Spinal Concepts needed a better way to track how and when they got product information out to their sales force.
Solution: We built them an extranet powered by our CMS.

Spinal Concepts is an innovative company that builds medical equipment for spinal surgery.

Their global sales force needs current information on the latest products, kits, and systems so they can sell effectively. They also need to get their hands on demo kits so they can demonstrate the power of Spinal Concepts solutions first hand.

Spinal Concepts asked us to build them a state of the art extranet portal. The portal tracks each salesperson by their unique ID, and gives them access to a variety of services:

• Quota numbers by product and month.
• An interactive dictionary of Spinal Concepts products
• Content pages for each product in their inventory, powered by our CMS
• A request tracker that allows sales personnel to make requests for different kits–and allows the request administrator to monitor kits in up to 7 status stations, including shipped, late, and committed.
• Access to their own accounts, so they can keep Spinal Concepts updated as to their current phone numbers, addresses, and other vital information.

The result: a dramatic reduction in time, money, and energy trying to coordinate the different product information rollouts. If the sales person needs support, they go to the extranet first.

Comments(0)

Whether you are writing ad copy, interactive materials, magazine how-to’s, or technical user guides, the subject of good information design is going to pop up.

What is information design? It’s just that, the intelligent design of information such that it is usable, understandable, and visible. Design (Latin designare, “to mark out”) implies a lack of accident, happenstance, or synchronicity. Design means to lead someone to do something, believe something, or
perceive something.

What do we mean by good information design? What makes a particular information design approach “good” or not depends on

• the reader of the material
• the subject matter
• the reader’s purpose

Some Examples

For example, if your reader is late to her appointment across town, and is perusing the subway map, she is most likely looking for the quickest, most direct path to her appointment. She needs to plan the route, and the information design should support her need. The map should have color-coded subway lines, well-marked subway stations, and well-marked exchanges.

On the other hand, take the case of the reader sitting at the opera, perusing the playbill and wishing to know who the beautiful lead dancer is. Good information design will help him with his goal: a picture of the dancer, her name in bold next to her photo with her role in parentheses next to her name, followed by a bio. The bio’s length can also help the casual observer of the playbill make assumptions about the importance of a performer’s role–long bio, lead role.

One of my favorite projects was creating a quick install card for one of Cisco’s network products. I found out that the person installing the product was not a typical user of the product, but a technician. Technicians typically spend their day scrambling around inside of hot wiring closets, lugging hardware onto racks, and testing connectivity. Obviously, the longer installation manual was no good. The information (the bits) was good, but the container (the atoms) didn’t fit the bill. They needed just the facts, condensed to something that would fit inside a shirt pocket.

I designed a tri-fold with 10 simple steps, including two diagrams (one of which was the back of the machine). Each step stood out because the step number was reversed out on a black box. On the last page of the tri-fold were 6 steps to test the connection, and an email address to contact someone for further assistance.

I have no direct correlative data to prove this, but the Cisco call center told me that installation support calls on this product went down considerably after the product started shipping with the quick install card.

Tips

So what else can you do to leverage the power of information design?

• People are busy, busy, busy these days. They scan for information, then slow down when they think they’re getting close to stuff that’s important to them. Make sure they can scan easily. This means short chunks of information, headers and headlines, and visuals.
• If you are writing instructions, modularize each piece, using active headers and cross-references to avoid repetition. Makes your instructions shorter and easier to scan.
• If you are writing copy or articles, using headers on longer materials lets your readers scan through the piece and find things that interest them.
• Use lists as much as you can. Use bullet lists when the order isn’t important, and numbered/step lists for procedures. Lists provide more white space, and give the impression of being short and easy to read.
• If you need to show the results of something, or need to compare one thing to another, use a table. It’s much more effective than trying to explain it all with words. Use paragraphs or bullet lists to embellish or provide analysis of the data in the table.
• Use diagrams to show readers what things look like (or should look like).
• Use flowcharts to indicate process flow.
• Use maps to indicate the relationship/context between two or more things (such as where you are in relation to an office suite or how to get to the park).
• Use charts to show progress (line/fever chart) or distributions (pie charts).
• With visuals (such as tables, graphics, diagrams, maps) always strive to reduce noise and junk. Excessive rules and gridlines on a table or fever chart just distract from the story you are telling. Excessive details in a diagram (like drop shadows or fancy fonts) cloud your message.
• With longer information pieces, provide navigation and context. This means a table of contents and index that provide different views of the content. Doing so will increase access to your content. Each page should have a page number and chapter header for wayfinding.

Comments(0)

Customer: Liaison Resources
Problem: Each week, Liaison employees faxed their timesheets back to HQ, a process that took too much time.
Solution: We built Liaison a custom timesheet application.

Liaison Resources has built a fantastic practice providing graphic design outsourcing for various Fortune 500 firms. However, the very nature of their work meant having employees at distributed client sites. They employ copywriters, designers, developers, system admins, marketing specialists, and many other professionals.

Every week, these employees would fax their timesheets back to headquarters, where one person would spend several hours logging time, checking errors, deciphering bad handwriting, checking project codes against a printed list, and sending the data through a scrubber and into the payroll and invoicing system.

We worked very closely with Dave Claunch, CEO of Liaison Resources. His requirements were pretty straightforward:

• A web-based system, because he had contractors all across Austin who needed to get in and log their time.
• The system had to keep employees from doing things they shouldn’t. For instance, they shouldn’t be able to log general overhead time or vacation time as overtime. Nor should they be able to log overtime before they’d worked 40 hours in a given week. Time that was logged for a job had to meet other criteria–it had to be a valid job, for instance, with a valid work order.
• Managers had to approve timesheets before they were routed to headquarters, but employees had the ability to send in their timesheets in case the manager was in meetings or out sick.
• The timesheet coordinator back at headquarters needed to be able to run reports on different data, collate and export timesheet data, purge records after exporting, and centrally manage important data like valid jobs, managers, and staff for each location.

Our timesheet collector was built in PHP 4 and mySQL 3.23 and deployed in early 2003, where it served the needs of 40+ employees and contractors. Before the system was installed, the timesheet administrator would routinely spend 10-15 hours a week running down timesheets. With a more automated process in place, this time was cut down to 2-3 hours per week. Which meant that the timesheet administrator was free to work on other, billable, tasks.

Comments(0)