Tuesday, March 24, 2009

Articles on some effective newer UI techniques

Mega Drop-Down Menus - which get a big thumbs-up from Jakob Nielsen. He likens them to the ribbon found in the latest version of MS-Office.

Contextual User-Interfaces. Chris Mahon gives some examples. They let the user perform relevant actions without having to shift context. And as the user performs actions, the UI is dynamically modified to take this new context into account, so the user can perform tasks more quickly and easily.

And while I'm here I'll give another plug to Bret Victor's visionary -- and still very relevant -- paper Magic Ink: Information Software and the Graphical Interface.

"It’s easy to make something incredible."

I believe that having high standards is probably the most important thing required for becoming good at anything.

Rory thinks so too

It’s easy to make something incredible. All you do is, don’t let what you’re doing be shit.
It baffles me that people think making really, really brilliant, stupendous, worldshocking pieces of work is a particular challenge. It’s mainly a battle of endurance. The longer you try and deshit something, the less shit it is.

Monday, March 23, 2009

Minatur Wunderland - world's largest model railway

5 min video of Miniatur Wudnerland, in Hamburg, Germany -- the world’s largest model railway, and actually quite impressive.

14kms of track, 6 meter high mountains, and highly detailed scenery that also includes moving cars and boats. The whole thing cycles through day and night every 15 mins.

Thursday, March 19, 2009

British man Sean Hodgson 27 years in jail for crime he didn't commit

Recent DNA tests have shown that a British man, Sean Hodgson, spent the last 27 years in jail for a murder he did not commit, the Times Online reports.

Wednesday, March 18, 2009

Programming is always a team activity

So you've written a bit of code. As time passes and you haven't touched parts of it for a while, they'll start to fade from memory, and if you need to know them again, you'll need to refresh yourself on them.

A week after you wrote a function, you may be a bit hazy on how it works. Six months down the line you might've forgotten all of the function's details. Three years later, you might have forgotten about the existence of the entire module.

Down the line you're no longer that person who knew the details of the code. The more time since you looked at a piece of code, the more it is like you're reading someone else's code.

So the entirety of your work on that code is more like a team effort than an individual one - your current self writing code for, and collaborating with, your future selves.

With the exception of simple, throwaway programs -- this is why you should always write code for others to read, even if you're writing something that no one else will ever need to touch.

Sunday, March 15, 2009

Coworking spaces

I just came across the notion of "coworking spaces"

“Coworking is cafe-like community/collaboration space for developers, writers and independents. Or, it's like this: start with a shared office and add cafe culture.”
I'd never heard of it before - it sounds interesting. These places provide facilities like wi-fi, printing, lockers, coffee and meeting rooms.

It seems like they've sprung up all over the place (at least in the US). Here's a smattering of examples: Office Nomads (Seattle), StartPad (Seattle), CubeSpace (Portland), The Network Hub (Vancouver), thinkspace (Redmond), Work Space (Vancouver).

There's one in Melbourne - OpenHub. Didn't see any others in Australia, though apparently this (Monash Enterprise Center and Business Center) works along similar lines.

There's even some general coworking resources: a wiki and associated blog, and a group on Google Groups.

Clay Shirky: Newspapers and Thinking the Unthinkable

Clay Shirky has an excellent post on the future (or lack thereof) of newspapers. Newspapers are going away, and it'll take us some time to invent alternative venues for journalism.

What Eisenstein focused on [in The Printing Press as an Agent of Change], though, was how many historians ignored the effects of the [printing] press circa 1500. To describe life before or after the spread of print was child’s play; those dates were safely distanced from upheaval. The hard question Eisenstein’s book asks is “How did we get from the world before the printing press to the world after it? What was the revolution itself like?”

Chaotic, as it turns out. The Bible was translated into local languages; was this an educational boon or the work of the devil? Erotic novels appeared, prompting the same set of questions. Copies of Aristotle and Galen circulated widely, but direct encounter with the relevant texts revealed that the two sources clashed, tarnishing faith in the Ancients. As novelty spread, old institutions seemed exhausted while new ones seemed untrustworthy; as a result, people almost literally didn’t know what to think. If you can’t trust Aristotle, who can you trust?

During the wrenching transition to print, experiments were only revealed in retrospect to be turning points. Aldus Manutius, the Venetian printer and publisher, invented the smaller octavo volume along with italic type. What seemed like a minor change — take a book and shrink it — was in retrospect a key innovation in the democratization of the printed word, as books became cheaper, more portable, and therefore more desirable, expanding the market for all publishers, which heightened the value of literacy still further.

That is what real revolutions are like. The old stuff gets broken faster than the new stuff is put in its place. The importance of any given experiment isn’t apparent at the moment it appears; big changes stall, small changes spread. Even the revolutionaries can’t predict what will happen. Agreements on all sides that core institutions must be protected are rendered meaningless by the very people doing the agreeing. (Luther and the Church both insisted, for years, that whatever else happened, no one was talking about a schism.) Ancient social bargains, once disrupted, can neither be mended nor quickly replaced, since any such bargain takes decades to solidify.

And so it is today. When someone demands to be told how we are going to replace newspapers, they are really demanding to be told that we are not living through a revolution. They are demanding to be told that old systems won’t break before new systems are in place. They are demanding to be told that ancient social bargains aren’t in peril, that core institutions will be spared, that new methods of spreading information will improve previous practice rather than upending it. They are demanding to be lied to.

Wednesday, March 11, 2009

Not needing to name or save documents - 'Untitled Document Syndrome' & OLPC

When I'm working with a document in a text editor or word processor, I don't want to be forced to give it a filename, nor do I want to have to manually save it.

It shouldn't need a filename - it should be saved anyway. And if I'd prefer to not give it a name, I should still be able to locate it based on when it was created, last modified, and by searching for terms that I know are contained within it (and perhaps by tags I've given it).

I shouldn't have to manually save it. It should automatically save the content as I type. I don't want it to automate periodic saves, I want it to be like paper - once a change has been made it's recorded and can't accidentally be lost. The user shouldn't even need the concept of 'saving' the document.

Related to this, John Gruber has written a post Untitled Document Syndrome that argues similar points.

Also, the OLPC system seems to work in such a fashion.

Tuesday, March 10, 2009

"More Americans say they have no religion"

Yahoo news, reporting on a recent study of religion in America (other reporting):

Fifteen percent of respondents said they had no religion, an increase from 14.2 percent in 2001 and 8.2 percent in 1990, according to the American Religious Identification Survey.

Northern New England surpassed the Pacific Northwest as the least religious region, with Vermont reporting the highest share of those claiming no religion, at 34 percent. Still, the study found that the numbers of Americans with no religion rose in every state.

Monday, March 09, 2009

Richard Baraniuk's TED talk on the Connexions open-source textbooks system

18 mins

Rice University professor Richard Baraniuk explains the vision behind Connexions, his open-source, online education system. It cuts out the textbook, allowing teachers to share and modify course materials freely, anywhere in the world.

Sunday, March 08, 2009

Jokey insults and threats

A joke is something that is funny.

But then there's things that are presented in a jokey fashion but which are not really intended to be funny.

For example, you can have insults or threats presented in a jokey manner that are really statements of solidarity or respect. E.g. a lowly business person saying the following to a superior"if you could look at that brief that'd be good, otherwise I'd have to do you in", where the last bit is said in an ironic fashion. That's really a statement of respect to indicate that they're well aware of their relative positions.

The case I want to talk about, though, is statements that are presented as if they were jokes but are really just insults or threats presented in a jokey manner. That is, insults or threats passed off as jokey statements.

The jokey manner may include a wink appended to the end of a written statement -- not that you guys are likely to understand what i'm talking about ;-). Or a chuckle or giggle appended to a verbal statement. Or they might be in the form of over the top threats like "...or we'll beat you to a bloody pulp - ha ha".

These aren't actually funny and aren't intended to make the person laugh -- even if social forces may compel them to do so.

As you may have guessed, I quite dislike these sorts of statements. Even if they're only carrying a quite minor barb, there's something dishonest there. Though I don't like this term much, childish comes to mind.

Thought: program hibernation

I can hibernate my laptop so it doesn't drain the battery when I'm not using it. What if I could hibernate individual programs, like my web-browser?

I usually have scores of web-pages open in my browser, and just having it open, even if I'm not actually using it, uses the processor -- often quite a lot of it -- and drains the battery.

So I might leave the house in the afternoon to go out and do some PhD writing at a coffee shop. I won't be using the browser there, and I don't want it to drain the battery, so it'd be nice if I could hibernate it.

That'd be quicker and easier for me than manually closing it down and then manually reloading it all, and guarantee that when I bring it back up everything is in the exact same state.

Current operating systems may have quirks that wouldn't make this feasible, but of course that doesn't mean there's anything inherently impossible about the idea.

Thursday, March 05, 2009

Information hiding for flyweight code units

To make code more readable we divide it into units like functions, objects and modules. Following the principles of information hiding we give these units meaningful names that express what their function is, and supplement that with comments providing additional details.

Once a person reading the code is satisfied that those statements do what the name or description says, they can skim the code by paying attention to the names/comments but skimming the details how how the named functionality is implemented. It helps conserve precious mental resources.

There are units of code smaller than a function –- a number of lines of code within a function that togther perform a fairly coherent function like reading a file -– that you want to be able to apply the principles of information hiding to.

I’m talking about cases where separating the lines of code out into a separate function would be too heavyweight a solution – doing so wouldn’t be worth the effort and would actually decrease the code’s readability.

One difference between these and the other units of functionality is that they don’t have some sort of explicit delimiter to indicate their start and end, and this makes the task more difficult. If you put the comment at the start of the lines, does it apply only to the first line or to all of them? If there’s uncertainty you have to look at the code to resolve it, thus destroying the good information hiding properties.

If you have a convention –- that it always applies to all the lines of code till the next blank line, for example -– then you have to learn and remember the convention, and other programmers can always break it by accident or forgetfulness or from simply not knowing it. And if you want to be able to have blank lines within that set of lines of code -– which is often useful to do -– then you have to have an even more complex convention.

Here’s a code formatting idiom that provides a solution to the problem. Write a comment at the start of those lines of code that names/describes the functionality they implement, and then indent all of the lines implementing the functionality:

function X()

statement before task

// comment describing task

statement implementing task
statement implementing task

statement implementing task
statement implementing task

statement following task
statement following task

A language could go a step further and have a way to use an explicit label instead of the comment, as in:
function X()
statement before task


statement implementing task
statement implementing task

statement implementing task
statement implementing task

statement following task
statement following task

This could
  • encourage a concise description of the function being performed
  • be used for documentation purposes
  • make it easier for an editor to collapse/expand sections -- i.e. collapse the code 'contained' in the label, so it just shows the label.
  • support refactoring by having operations turn one of those sections into a full-blown function.
I don't know whether such labels would be better to have or not.

Tuesday, March 03, 2009

Thought: A Stack Overflow for finding research material in a subject area

Quick sketching:

Here's an idea for a website.

If you wanted to do some research that touches on a field you didn't know that well and wanted to find out what material -- previous research and so forth -- was relevant to your topic, it'd be useful if there was a dedicated website for asking such questions, where you could get responses from people with expertise in the field.

I'm thinking of a site designed like Stack Overflow, which can build up a refined body of knowledge.

Ideally, it'd be a exchange of information between disciplines, and between those with expertise and newcomers. It'd help research that crosses disciplinary boundaries. It could also help out students that are new to an area, or people undertaking amateur research (which I think is important). It could help academia open up a bit more. These are of course just lofty possibilities.

I imagine some people would not want to make such things easier - seeing it as somehow cheating. I don't see it that way. The idea is to help reduce the friction in undetaking research, and give people more time to focus on the more central aspects of research - finding patterns, synthesising new ideas, etc.

If there were something like this, it'd probably be good if students / academics got some amount of institutional recognition for contributing answers. Like they do for for writing papers (not saying it should be the same amount of recognition of course).

It wouldn't have to be a website, it could be the name of a tag -- like existingMaterialReq -- used in blogposts and/or Twitter to get help from the lazyweb. Probably the most important thing is simply to name and communicate this notion of a request for relevant material in an a subject area.

'The Minute Glass' alarm clock

The Minute Glass is a design concept for an alarm clock that forces you to shake it vigourously for around 30 seconds – and hopefully thus properly wake up – in order to turn the alarm off.

Monday, March 02, 2009

"Syntax highlighting" for diff

I just saw a reference to Sentdiff -- take a diff by sentence, not just by line -- over on Hacker News. I'd like to see a diff program that allows you to customise how it shows changes. Is there anything like this?

What are alternative ways to show changes? Consider Word's track changes feature, for example:

The best way to show changes, including what you want to consider as the 'units' that are being changed -- sentences, lines, etc -- really depends upon what the information in the document represents.

Perhaps you might want to show changes to a datafile with tabular or CSV structure differently to a file containing C code, for example. Or perhaps you might want to handle two different tabular-data files differently, because the types of entities they are describing are different - you parse them differently when you read them, or you think of them in some sort of different way... I feel pretty sure there's examples out there.

Think of it as like how text editors allow you to specify different syntax highlighting schemes, that colour different aspects of the documents in different ways, reflecting what the information in the document represents.

For that matter, it'd be good if a diff program could highlight syntax in exactly the same fashion as a text editor does - so if you're viewing a diff of a Java program, the document fragments it shows are shown with Java syntax highlighting.

Sunday, March 01, 2009

Jorn Barger on what Twitter is useful for

For someone who (like me) has never used Twitter, this summary of what it's useful for seems pretty insightful.