Monday, May 29, 2006

Simply do a complex thing, with content

(I know in the blogoverse they call it a meme, but in the big media world it's just ordinary that everyone writes about the same thing). I keep running into articles, like this one on, based on a J.D. Power survey indicating that people think cell phones are too complicated for their needs. This is true for a number of people in my family- big buttons, bright screens you can read in the sun, loud ringers, one touch phone book- those are the features they're interested in.

Usability is important- and yes a lot of people don't use most of the stuff on the phone. Back in my youth, or 10 years ago, or sometime, I remember the GIS greybeards scoffing at ArcView because it didn't do anything useful. They were slightly appalled that my team had hacked it up to do coherent multi-user editing (end users weren't allowed to create geodata back god, they don't even know about albers equal-area conic, how can they click on the map and make data?). It was a heck of a lot of work to make that easy.

I think people are waking up (again?) to the fact that it is hard to simply do a complex thing, and maybe even realizing that it's even harder when you are trying to do "too much".

DVD vs VCR- Is the DVD player more usable than the VCR because it is not a recorder? I almost never have my parents call me for DVD player help. Most VCRs I have used require you to turn the unit off to enable the timer based recording. Maybe it's there because someone in some meeting raised the possibility of problems with accidentally taping over treasured personal recordings, but it seems more like insanity. I really shouldn't have to turn something on to make it work...

We now have a purpose built device that lets people do what the record part of the VCR was supposed to do- record tv when you weren't watching. Surely it will soon be a relic of the broadcast age soon, but the DVR really is the true answer to the problem. I don't want to figure out when my show is on every week- I want you to do it.

I don't quite understand the XM radio recorder (DAR?)- unless you want it just to skip bad songs or you could program in artists you wanted to record. In fact, if someone can figure out how to figure out what song is coming next, you could make an actual Tivo of everything on XM. Almost makes you understand why the RIAA has sued them. Actually, you don't need to know the program schedule ahead of time if you just record a small buffer of the channels of interest so that you could keep the songs you are interested in once the artist information is transmitted. Anyway, when it gets to the point where I can type in "Clap Your Hands Say Yeah" and then have them in my queue to listen to...

The question of the non-broadcast future is- who's the DJ? If we are all getting content on demand- who is telling us what to demand? Well- we end up getting broadcast things from sources we trust, like trusted reviewers, our friends, blogs, that give us things like mp3s we should listen to, that lead us to content to demand. Are bloggers the DJs of the on-demand era? I guarantee I am not the first one to have that mundane thought, but I am too lazy to Google any others at the moment...

Wednesday, May 17, 2006

Wow - google web toolkit

This is something new:
"Google Web Toolkit - Build AJAX apps in the Java language"

You write (and debug) the web app, in Java, and this thing "compiles" your code into JavaScript and HTML. It's probably more accurate to call it a JavaScript/HTML code generator. Plus a framework of sorts for dealing the with traffic.
turns things upside down. I have been playing with Dojo and using Prototype and Scriptaculous, but this is more like RJS, the new JS generator in Rails 1.1.

This would have really appealed to the me of three years ago that had no interest whatever in learning JavaScript. I was perfectly happy doing I am getting back into the dynamic/scripting thing that I had abandoned for Java, and I don't need this as much, but it is still a useful idea.

Downsides, needs a lot of pretty. Upside- the back button handling and most of the API is well done. I may have to look into how it might be used on a java web project I work on occaisonally...

Monday, May 15, 2006

Lawyers, Genetics, and the Wiimote

Signum sine tinnitu--by Guy Kawasaki: The Top Ten Lies of Corporate Partners: "4. “Our legal department won’t be a problem.” In other words, the legal department hasn’t seen the proposal yet. There are two kinds of legal departments in large companies: (a) the kind that automatically says, “No,” when asked, “Can we do this?” (b) and the kind that automatically says, “No,” when asked, “Can we do this?”"

I am not really looking forward the day when I need to run everything by the lawyers. It's not that I don't like lawyers or legal thought, in particular examing all of the possible scenarios that must be addressed in a contract is something akin to figuring out all of the possible input conditions on a piece of software. You even get to write up those scenarions in language that most people can't read. I just don't like how it tends to make small points define business direction- especially when people don't want to do something because they don't want to go through the trouble of asking the lawyers.

Of course, I learned everything I know about law from Phoenix Wright: Ace Attorney. I would like to see more realistic scientific games- it would be more fun for me to solve cancer than do a cross examination- "Tucson Wright: Ace Geneticist". (somehow, re-mission doesn't cut it.) You could use the "Wiimote" (is it really called that?) to pour stuff from beaker to beaker.

I defy anyone to watch the Nintendo Wii promo video and not be impressed by the fun factor. I like the whole marketing philosophy behind it- focusing on the fun factor and letting the other companies worry about pixels and polygons and frames per second and exploiting the hardware. Of course, the combination of both manages to be exciting as well. I have heard of all of these virtual globe applications that aim to be both fun to navigate, and push the limits of what can be displayed. It would be fun to use a Wiimote style controller in Google Earth- I am getting pretty pretty proficient with the middle button, so much so that I don't know what to do when using it on the Mac.

The only thing missing is cool sound effects when panning and zooming around the globe. Maybe someone should build a little plugin that puts a soundtrack behind Google Earth. It would play cool effects when panning around? The music would get faster when you pan faster? It would get more intense when you zoom in? It would music of the area you were currently zoomed in over? That's me off to collect whale songs of the nothern Pacific for another project I'll never finish....

Friday, May 05, 2006

GAO preaches on software development model

GAO preaches on software development model: "By contrast Motorola, as well as other large commercial companies, spend just a few percent of its budget on rework.

This huge difference, according to Carol Mebane and Cheryl Andrew of the Government Accountability Office’s weapons acquisition audits practice, is based on a structured, replicable approach to software development that emphasizes requirements planning upfront. Three years ago Mebane and Andrew spent months studying how commercial best practices could be applied to DOD projects to control both cost factors and schedule slippages.

There's some good and some bad in here. First off- weapons acquisition is a little different than software acquisition, even when it's software that runs on weapons. Second- WTF is it that makes everyone think they can magically figure out all of the requirements for their software before they try anything to see what works? Maybe these two geniuses should read the IEEE Computer paper about Motorola's experience with Agile Software Development practices. Or about their Agile approach to Six Sigma?

"Get all of the requirements right before you do any work"- this is a fake solution to avoiding rework. Sure, you can control schedule slippages if you build exactly to the requirements, with the general problem being that you end up building what the requirements said, and not what was needed. Requirements change. Adapt to that fact of the world, don't try to change the world to make requirements static. You will lose.

Fortunately, this crack GAO team has realized that most DoD projects are way too long. "Creating a manageable environment means breaking software projects into manageable pieces, each generally with a six-month schedule." But then it gets scary:
“Based on our discussions with individual [companies], three factors determine” the success of a software development program, Andrew said. “A manageable environment, disciplined processes, and metrics, metrics, metrics.” First of all, that's 5 factors ;-), I like the first two, but what metrics do they mean? If the start measuring delivered, working code- okay. If they measure lines of code or design documents created- I'd be a little worried. (and yes, most CMMI processes I have seen measure productivity or progress in terms of pages of design/requirements documentation)

Well, I am glad to see the government taking some steps to save us money on bloated software development projects: Shorter project cycles- good, all requirements up front- highly questionable, metrics- dangerously vague!


The Art and Science of Being an I/T Architect: SAP Disrupts Everything It's a frightening little piece on SAP upgrades- which the upside being that there's going to be a lot of work for consultants- even IBM is raising an army.

I saw a comment from Scott Mark on this that said..."talk about enterprisey - this is *exactly* the situation that large companies end up in; serious roach motels - for however complicated WS-* seems, it beats this kind of lock-in!". That seems like a false dilemna- it has nothing to with WS-*, it just proves that buying enterprise systems is potentially worse than building them yourselves.

It's not like SAP or one of the companies Oracle keeps buying have figured out some real significant technical problems that your above average programmers couldn't figure out. It's not a 3D GIS or even a database something like that- it's a business system that pushes dollars and nonsense around a company. So, of course, you end up customizing it, and, of course, you end up doing massive amounts of integration work (just to integrate the internal components), and of course, it when the underlying base software changes, none of your stuff works.

I'd like to propose simplifying business processes as a good way to make your software work better.

Thursday, May 04, 2006

In the beginning...was the command line

All points blog on Google OneBox

Google OneBox -in case you don't get the pun, as my friend Carl pointed out to me the other day that a lot of people don't get that refers to the one search box. I love the one box- and I love using it to do other stuff (define:, movie:"name" zipcode, weather:zipcode, etc.) I think about it as a simple command line.

I am big time in favor of having a command line in my apps. (An interactive scripting engine works too.)

What's so cool about a command line? First, read the book.
Commands are simple ways of doing complex things.
You get a history of what you did. (I have seen this other apps too where it keeps a record of your steps and lets you return to previous steps- that's one better!)
Batch files...

In so many cases it's faster to get things done with the command line/typing than clicking on stuff. I have gotten into a great habit of the double ctrl trick with the new Google Desktop to launch applications. It's so much faster than the start menu, which seems to require extra clicks with each iteration of the Windows OS.

The Google Desktop launcher has brought forward a capability that has made the command line more powerful: the relevance ranked list of suggestions that pops up as you type. Beyond saving time, this helps get past one of the greatest obstacles to command lines- not knowing what to type. One reason it's easier for novices to perform most operations in GUIs is that they can literally look for the option they want, they don't have to remember it.

There is a simple beauty in using the "tab" key to autocomplete, which I first saw in the bash shell- which is now in the windows CLI as well. But, what if it was more like code completion, where it popped up a list of the available options. With documentation. Really, this is what a menu based GUI is, but turned on its head to put the command line back in charge...

Meta Post: Link lovers of the world, unite and fall over

Guy Kawasaki is obsessed with making it into the technorati top 10. It's a little weird to see his "evangelist" act effected on himself- instead of the Mac. So, I guess I am falling into his trap and giving him some link love, but the guy is really cool. I love his books- "Art of the Start" is a good guide for starting just about anything (a project, a department, a company, etc.). But you really shouldn't start something of your own- you should come work with me and my burgeoning enterprise.

I am wondering if his technorati top 10 obsession comes from his own top 10 list thing, like the top ten lies of engineers. I think it's going to be hard for him though- most of the top ten are written by a group of people and are of more general interest than a business blog. Some aren't even written by people at all- I can't believe so many people read that Michelle Malkin malarkey.

Anyway- I don't get a lot of traffic on this blog, but it's fun anyway. I don't get a lot of comments either, but I have been trying to be careful about responding to comments in the comments quickly so that it becomes a bit of a conversation. I guess links are nice, but I'd rather interact with people.

Cheers to the readers...

Wednesday, May 03, 2006

WWML spec

A few interesting tidbits from the WWML (NASA World Wind Markup Language) 0.93 spec. It adds a few concepts on to GML. It mixes in GML, with the gml namespace, where appropriate and keeps it's own stuff (metadata, display, and dynamic properties) in a wwml namespace. Beyond that, I see no advantages over using KML...

"WWML is a NASA open specification standard that is aimed at becoming the de facto HTML/XHTML extension standard for streaming geospatial data over the internet."

Looking at it as an HTML extension seems to imply that it is intended to focus on the display of map data in web pages. It also implies something quite different from KML, but they compare it to shapefiles... KML is notably absent from the spec, while shapefile is referred to 11 times, and it obviously borrows heavily from KML (as KML -borrows- from GML) It would seem that they wanted to avoid discussing the whole issue of divergent standards, although there are quite a few references to this being a superset of GML, much like KML is.

"Therefore, very rich XHTML documents can be designed for future web-browsers that enable WorldWind type rendering and interaction capabilities."

An interesting idea...but this seems to be irrelevant at the moment- when will these browsers exist?. Defining XML "fragments" that can be embedded in other XML formats really seems to be the only outcome of this notion. I think when when we start to see broader SVG support, that will be way some of these ideas end up getting implemented. I don't see internet explorer building in wwml support any time soon.

"WWML will support binary compressed XML files BXML proposed by CubeWerx and currently implemented in and open-source C-language library for parsing and generating XML and BXML formats under the GNU LGPL license."
I think the ZIP approach (KMZ, gzipped html) is a lot more common than BXML, but they claim that doesn't offer enough compression.

The meat of the spec is the concept where you define display rules for something like wwml:City using a mixture of gml:Feature style with some extra wwml elements , and then use a tag to wrap gml geographic features and their attributes. It seems a little clumsy.

From a parsing convenience standpoint, I don't like to see new elements introduced as attributes of other elements. It usually means you have to parse most of the document to understand it, instead of being able to pull out the bits you want quickly with expressions. For example, I'd have to read all of the feature style definitions to even know I was supposed to be looking for a tag. I think this is one of the things that makes it really easy to write code for KML, the set of tags to expect is small and predefined.

And here, wwml:City is just a display style- not a semantic concept of a "City" with population attributes, etc., those attributes are merely referenced as XPath expressions in the display rules and then become more suprise tags in the placemark definition. You just wrap all of the city placemarks (which are gml:point or the like) in the wwml:City tag (with wwml:name and wwml:population tags inside) to have the display rules applied. If I were writing this I might not use city as my example, it's really more like a styleurl in KML.

Overall, it's a pretty interesting spec. It's a little messy to look at and the domain/range stuff is just plain ugly, but no one was ever meant to read XML- right?