New Now Know How

I’m busy finishing my thesis.

Can’t blog. Writing.

Back later.

I use LaTeX to write my thesis in. Like C, it’s user friendly, but picky about who its friends are.

Recently, I’ve been fighting with LaTeX over using the pdftex processor but only while at uni. It worked at home, but not at uni. At uni, to produce PDFs from LaTeX I had to go through the dvips processor. Normally this was not a problem, however, pdftex has the lovely property of being able to insert .jpeg, .png and other graphics formats as pictures, rather than the limited support that dvips offers for .eps graphics files only. When I tried to use pdftex at uni, it would fail with:

! LaTeX Error: There’s no line here to end.

I had put the fact that I could only make pdftex work at home down to some weirdness in the installation of my LaTeX implemention here at uni. However, I was able, recently, to use pdftex to compile a file that was on my flashdrive but I was unable to compile a file that was on my networked drive. Why? Why? Why?

After a small amount of banging my head against the wall, the solution became apparent.

Googling for that error message let me to the TeXFAQ for no line here to end which told me that the error:

comes in reaction to you giving LaTeX a \\ command at a time when it’s not expecting it.

I wasn’t giving any \\ commands as far as I knew! I was at the point of creating LaTeX files of the “Hello World” sort before the penny dropped.

The networked drive I use is (obviously) mapped to a drive letter. It’s also mapped to “My Documents”. I was opening the file from “My Documents”. Apparently, “My Documents” is a convenient fiction that all programs see as a full path. In windows, the path to a mapped drive is “\\name\of\server\to\users\path”. Notice the (un)helpful “\\” at the beginning of that path?

Solution? Open the file from the pseudo-name given to the mapped drive, that is “h:”.

Arrrgh!

Ricky writes about a conversation that we had on, among other things, seamful and seamless computing. As ever with this ongoing debate between Ricky and myself, I think we agree on more than it seems we do.

Jumping right in with an example of where we agree more than disagree:

Furthermore, this talk of having computers blending with the natural environment is a complete red herring, designed to draw your attention away from one of the real goals of ubiquitous computing, which is simply to release users from explicit interaction with technology as far as it is possible and sensible to do within certain applications of technology. The extent to which this is possible and the degree to which it remains sensible is determined by the users themselves. [my emphasis]

To which I say — sort of. The extent to which users are able to not explicitly interact with technology rests with designers in that the designer is the person who makes interaction possible (and the converse is also true). The degree to which it is sensible to not explicitly interact with technology is with the user and how they are using the technology in question. I think Ricky is saying (see emphasissed sentence in above quote) that the degree of invisibleness of a technology is a dynamic thing. It’s on a continuum with invisible/implicit at one end and visible/explicit at the other. Ideally, a user is able to negotiate that continuum themselves, being aware of when they are and are not “using” the technology.

Ricky’s example of RFID being a “different kind of visible!” is a good one. As Chalmers & Galani (2004) said:

“underlying infrastructural mechanisms are ‘literally visible, effectively invisible’, in that everyday interaction does not require attention to these mechanisms’ representations–but one can selectively focus on and reveal them when the task is to understand or even change the infrastructure.”

Invisibility or seamlessness is constructed (or, if you like, performed) by the people using a technology. To varying degrees the technology is “literally visible, effectively invisible” because the users make it that way. This happens already. To take a technology for granted is to render it effectively invisible. The many layers between my desktop computer and the internet at large are invisible to me. I can delve into them if I choose but there is typically no need to do so. The same is true of many other taken-for-granted technologies.

Making the transition from invisible to visible might be necessary for a lot of different reasons. Somthing’s broken. Something’s breaking. Something needs re-configuring to make a new thing happen. The thing can be used both implicitly and explicitly and the time has come to make the move. And more besides. It will be possible to design things that are so simple that it is easy to learn to treat them as invisible and never have to render them visible again. However it will also be necessary, as ubiquitous technologies become more sophisticated and begin to do more for us, to be able to shift these technologies into the foreground, or indeed to be able to not treat them as invisible in the first place.

I think that seamlessness and seamfulness are less about whether things are or are not invisible but whether it is possible to make the transition from invisible to visible and back again if the need arises. Depending on the depth of what you want to be (in)visible, this either has very little to do with the actual nuts and bolts (or 1s and 0s) of ubicomp infrastructure or it has everything to do with it.

It’s pretty common among mobile technology geeks to point at how the Japanese use their mobile phones as a view of the future of the mobile in the west. According to anthropologist, Mizuko Ito, that’s not necessarily the case. In a typical example of technological determinism:

In conversations about technology in Japan, the assumption is that there is something inherent in a particular technology that makes it get taken up in a particular way, and it’s not inherently culturally specific. But at the same time, if there is something that seems different from how other countries have taken up a technology, it gets attributed to the cultural strangeness of the Japanese, i.e., if the Japanese don’t use cell phones like people in the U.S. it must be something cultural.

This is the falacious argument that if a technology succeeds then it was something in the technology but if it fails (to replicate successes) then there was something social that caused the failure. Ito says that a better explanation is to look at the “technological trajectory” in each country as a way to explain the differences (and similarities).

The U.S. is an incubator for advanced PC Internet technology, and Japan is at the other end of the spectrum. The reason the Japanese are doing more diverse and cool things with their mobile phones is because they’re depending on them more as their primary information devices. It will continue to be an incubator for interesting mobile technologies, but is certainly not the site were you should look for everything IT.

Apparently tomorrow is World Usability Day. The slogan is “Making it Easy” which is generic enough, I suppose, but pointless and in my opinion, downplays what usability really is.

Tom Stewart wrote recently for the BBC:

Now, I have no objection to making life easier but I believe - and I’m supported in this view by an international standard - that a usable product or service has two other key features in addition to being easy or pleasant to use.

It must also be effective and efficient. In other words, the interface to our personal mp3 player should actually allow us to select the right music with an appropriate degree of effort and also be nice to use.

This approach to usability involves focusing on what users are trying to do with the product and making sure it delivers results without requiring us to be rocket scientists or contortionists. It doesn’t need to be easy - it depends on what we are doing.

It depends on what we’re doing. Context is important. A hammer is easy to use, until you want to make soup. Experience is important. Unix is easy to use but only if you know your ls from your rm *.

Usability is really, really important. But there’s a lot more to usability and making something good to use (as opposed to easy) than the trite slogan suggests.

On a lighter note, I’m going to put a usability violation ticket on my Mum’s stove. Take that, poorly designed stovetop!

I’ve been trying to follow David Allen’s Getting Things Done (GTD) methodology for a while now. It works, I like it, but I’m slack. I backslide every other day.

GTD relies on lists. Lists of projects, lists of atomic (monadic? ha!) subtasks (called next actions), lists of things you’re waiting on. The problem I’ve had, until recently was keeping those lists in some sort of order that made sense for me. What I wanted, and what I thought made sense, was to tie next actions to projects in some way that I could see all the next actions for a particular project but at the same time just see my whole list of next actions.

I’ve tried keeping the lists in Outlook and Palm’s surprisingly good Palm Desktop, both of which proved too clunky for me. It was too hard to add new projects and next actions and particularly too hard to tie the two together.

MarkTAW’s “Cascading Next Actions” was the next step, and an excellent paper-based solution, but still too clunky for what I wanted when maintained in a series of text files. A “projects” file and a series of files for each project quickly gets out of hand.

Enter wikidPad. WikidPad is sort of like a wiki and sort of like a basic text editor. It’s more like a wiki. It runs natively on Windows and is written in Python. It’s also open source.

WikidPad, out of the box, doesn’t do everything I wanted. As a wiki, It’s great for keeping lists and other information. But it only works top-down. That is, I can keep my projects list with sub-lists of projects but I can’t get a list of next actions out of it. That is, not without a little scripting.

WikidPad lets (nay, encourages) the user to hack it. A number of enterprising people have hacked wikidPad so that it does exactly what I want of it. Lists of projects; lists of next actions generated on the fly. Awesome. And all thanks to a few lines of python.

The promise of computing technology dissolving into behavior, invisibly permeating the natural world around us cannot be reached. Technology is, of course, that which by definition is separate from the natural; it is explicitly designed that way. Technology only becomes truly invisible when, like the myriad of pens sold in Japan’s department stores, it’s no longer seen as technology at all. Deliberately creating something ‘invisible’ is self-defeating. I can think of few recent technologies as visible to the public as RFID, no matter how physically ‘invisible’ it might be.

The point being, that you can’t design something to be invisible. It becomes invisible as people make it part of their lives, as it becomes part of the “fabric of society” or just something that people take for granted.

Design for appropriation is where it’s at. Being aware of the seams between things rather than making the seams invisble. Seams are useful. Edges make things clear. Inside. Outside. Here is the street. Here is the footpath.

I just finished Freakonomics. Good but ultimately unsatisfying, like half a cup of coffee with no cake.

I thought The Tipping Point, which is sort of in the same style (that style being the non-fiction best-seller), was better. More coffee. And cake, too.

Occaisionally these emails come around the uni email lists:

We will be running a workshop exploring how to use Word efficiently with long documents. The workshop will look at the various functions you might want to us when writing a thesis, mainly related to formatting the document to avoid having a document that seems to have its own life.

I love LaTeX.