|
 |
26 January 2004 |
|
03 June 2003 |
Sign up now to support Lawrence Lessig's petition to reclaim the public domain:
"We have launched a petition to build support for the Public Domain Enhancement Act. That act would require American copyright holders to pay $1 fifty years after a work was published. If they pay the $1, the copyright continues. If they don’t, the work passes into the public domain. Historical estimates would suggest 98% of works would pass into the pubilc domain after 50 years. The Act would do a great deal to reclaim a public domain.
"This proposal has received a great deal of support. It is now facing some important lobbyists’ opposition. We need a public way to begin to demonstrate who the lobbyists don’t speak for. This is the first step.
"If you are an ally in at least this cause, please sign the petition. Please blog it, please email it, please spam it, please buy billboards about it — please do whatever you can. And most importantly, please help us explain its importance. There is a chance to do something significant here. But it will take a clearer, simpler voice than mine."
5:14:45 PM 
|
|
|
28 May 2003 |
Bob Baxley writing at Boxes and Arrows about his impressions of the recent ETCON:
"[My] biggest takeaway from the second annual O’Reilly Emerging Technology Conference was that emerging technology is not nearly as interesting as the emerging uses of technology. What I heard had a lot more to do with politics, power, individual choice, and collective action than it did with PHP, CSS, XML, or XHTML.
"Most interesting for us as a community of designers and user advocates was the obvious subtext that technology has reached a point where users—actual real people—are the defining element of the human/computer relationship."
12:41:33 AM
|
|
|
27 May 2003 |
Predictably good commentary from Jim McGee taking a second look at weblogs and knowledge management, summarising and drawing together a number of strands from recent blog posts.
His closing comments are worth dwelling on. Talking about a post by Gary Murphy at TeledyN, he says:
"Murphy provides the critical link here between weblogs and organizational need. It is the realization that KM in organizational settings is primarily a social phenomenon and not a technology one. Most prior efforts to apply technology to KM problems in organizations have been solutions in search of a problem. They have been driven by a technology vendor's need to sell product, not an organization's need to solve problems.
"Weblogs are interesting in organizational KM settings because weblogs are technologically simple and socially complex, which makes them a much better match to the KM problems that matter. One thing that we need to do next is to work backwards from the answer - weblogs - to the problem - what do organizations need to do effective knowledge management. We need to avoid the mistakes of other KM software vendors and not assume that the connection is self-evident."
Focus on that "technologically simple and socially complex" and keep repeating it as a mantra whenever you're thinking about KM systems - and especially when a KM vendor is trying to jargonise you into submission.
9:54:24 PM
|
|
|
21 May 2003 |
Jared Spool writes about The Quiet Death of the Major Re-Launch, promoting continuous design improvements over the big-bang all-or-nothing redesign of a site.
Towards the end of the article he talks about how task success is key for users - and how it influences users' perception of the design:
"Our findings show that consistency in the design plays second fiddle to completing the task. When users are complaining about the consistency of a site, we've found that it is often because they are having trouble completing their tasks. On sites where users easily complete their tasks, the users seem to pay little attention to glaring inconsistencies, often telling us in their ratings that the site was indeed very consistent."
This is an interesting but not entirely surprising finding. Intranets and portal-style sites often provide a gateway to a number of distinct applications - if each of the applications works well for the user, design differences don't seem very important. Of course, all things being equal, design consistency is a good thing and enhances usability. But the usability of an individual part of a site shouldn't be compromised at the altar of consistency.
When I teach web design or mentor developers, I typically have to revisit consistency again and again. This applies both at the interface and within the code itself (consistently structured code is much easier to maintain - and is usually better written in the first place as it benefits from good practices and proven patterns). There's a lengthy process of getting people to understand simple things such as if the save button comes before the cancel button on this form, it should be in the same place on that form - or that standard navigation links should appear in the same place on the page throughout the site.
But once that lesson has been drilled in and become second nature, it's time to start questioning it. Sometimes slavish consistency doesn't work - sometimes it makes sense to move something or do something differently so that it works better in this particular instance. Consistency aids usability, but usability always trumps blind consistency.
And to return to Spool's theme in the article, this often comes up during an evolutionary redesign. You realise that the standard for the site isn't as good as it could be and you start to deploy sections where different rules apply. Any discomfort the user feels for the change should be outweighed by the benefits of improved task completion. (Of course, if it's not you're losing out on both sides and should quickly rethink your approach.) So consistency and house standards are good but usability is better.
10:33:39 PM
|
|
|
17 May 2003 |
I finally bought a Mac this week, primarily as a test platform for web apps. It's a G4 iMac - one of the weird hemispherical ones with a flat screen on a pivot. And yes, the choice of model was at least partly influenced by the fact that it looks more fun on my desk than all the grey and beige Windows and Linux boxes stacked underneath.
It's about ten years since I had a Mac and so far I'm impressed. I plugged it into my primarily Windows network and it found its way out onto the Net without the slightest hassle. I've downloaded a batch of browsers for testing purposes and installation was completely painless - no wizards and awkward questions about where I wanted to put what.
It's a pity it's not going to do anything more exciting than running web browsers and testing new versions of web apps. If I get time, I'll take a look at the developer tools and maybe poke around under the hood a bit.
11:58:15 PM
|
|
An interesting article by Stowe Boyd on social software, talking about what it is, what's the big deal and why now. Trying to answer the question of what social software is, he suggests three premises:
- Support for conversational interaction between individuals or groups
- Support for social feedback
- Support for social networks
And he concludes:
"Social software allows us to create new social groupings and then new sorts of social conventions arise. Kenneth Boulding, the economist, humanist and social scientist, once wrote: 'We make our tools, and then they shape us.' That is what social software is doing. It is changing the way that we socialize."
There's a lot of talk at the moment about what social software is and isn't, and whether or not it's a new thing. Very little of this really gets us anywhere. I'm not sure we can identify a particular class of software that's social software in the same way that we can identify word processing apps or content management systems. For me it's more about the usage - it's the social that's important, not the software - the software is just something that enables and mediates the social interaction. This blog runs on Radio, which is basically a lightweight CMS. There's nothing inherent in it that makes it social software or excludes it from being social software. It's a question of what it's being used for - which means, of course, that the same software may be social in one context and not in another.
I think this is part of what Stowe Boyd is getting at. What's interesting about social software is what it's doing in terms of the way we socialise. It allows us to extend social interactions and take them online in a way that more institutional solutions like groupware can't.
And why now? Boyd points to technology and money: low-cost, high bandwith tools and wider Internet access. Maybe. But certainly from my standpoint the interest was triggered by the failure of the first round of web applications to address social interaction in any meaningful way - and the impact that had on projects in the organisations I work with. During the dot.com boom there was an exuberant explosion of web-based software just because we could - it was playtime for the technologists and we built stuff because it was easy and because it was fun. We didn't always have a clear idea of where it might be going, but we had a heck of a time getting there (or maybe getting somewhere else we didn't expect - that was part of the thrill). But a lot of our so-called solutions just didn't cut it, or they were solutions to problems that the organisation didn't really have. We had the technology down and we weren't too shabby on the process - it was just the people we sometimes left out.
Turning things around and starting from the people not the technology has been the main spur for my interest in social software. And I don't think I'm alone in that. It's a penny that's dropped for a lot of people and is at least part of the reason that social software is a hot topic today.
As to whether or not it's new - who cares? Some of it is, some of it isn't - some is a new spin on old tools, some is taking what came before and co-opting it to the new slogan - some is simply re-invention or recognition of old wisdom from other fields. If the term "social software" helps to get across an important message about the priority of people and their social interactions, then it's doing it's job.
[Thanks to Clay Shirky.]
10:09:05 PM
|
|
|
16 May 2003 |
David Reed writes that security doesn't create trust - that building security into a system is more likely to foster mistrust:
"I think there may indeed be technological mechanisms that promote trust*. But don't try to tell me that security technology creates trust. It can't. At best it's neutral, and upon reflection, most times it increases mistrust and fear."
His footnote about technological mechanisms that promote trust says:
"Humans gain trust by interacting and 'getting to know' people. Transparent technologies that make it easy to see what people and companies are up to (in a sense the opposite of firewalls) are what help me trust. I like Reagan's saying: 'trust, but verify'. It implies that trust requires means for openness, not firewalls and secretiveness."
This is related to the comparison between hard security and soft security that I wrote about recently. Soft security is supportive of trust - it says that I trust you to behave responsibly and in good faith (although I will hold you accountable if you don't). Hard security, insofar as it is about trust at all, is often an admission that there is no trust and that we must impose constraints and controls (technical, legal or social) in order to interact.
3:17:01 PM
|
|
© Copyright 2004 Simon Forrest.
|
|
|
