Import, Export, Up, Down ?

On a web page (in this case a calendar service on the web) would you really use the DOWN-arrow for import (i.e.UPload to the web page) and the UP-arrow for export (i.e. DOWNload from the web page).


Rather confusing, I thought.
Why not use an arrow that goes INTO a box for import and an arrow that goes OUT OF a box for export...

Bad webpages

While trying to get some answers from the electronic timetable for the mass transit in and around Vienna, I had to cope with a site that makes about every web-mistake in the book (at least in my book).

1. They give you those ancient redirect warnings / helps ("If your browser does not support ...") in 2007 !! A web page that is full of frames assumes that frames do work, but redirects don't.
   Very likely ... and annoying.
   


2. They are totally up-to-date with their list of supported browsers:
   
   • MS Internet Explorer 6
   • Netscape 7
   • Opera 7
   Ever heard of Firefox ? Safari, anyone ?


3. In their search form they use bureaucratic terms like "Anfordern" (sorry for the German) etc. I just want to search and not "apply" for an answer...


4. They don't know when to use drop-downs or radio buttons. Take a look at this search form
   
   The radio buttons are supposed to change the meaning of the second entry field. In the first field you enter your city, in the second one either the name of a station/stop (if you know it), or a street address or any point of interest.
   Would you have guessed that from the layout ?
   Why not do it with a drop-down like this:
   
   


5. And please get rid of the "Start" label... this is not a multi-page wizard that guides me through a complex query, it's just one simple page...

Anyway, you can guess that I don't like this page.

From one to many

Last weekend I (again) discovered what every programmer / architect knows anyway:

The step from doing something on ONE item to doing it on MANY items is the hardest.

And there's an add-on:

Moving from ONE to TWO (in the above sense) is more complex than from TWO to MANY (unlimited).

The reason for the latter is that (to me) "2" is still not as generic as "n", or as I like to put it:

2 is just a special case of 1

quite often if you (in code) have to do something specifically twice, you don't use any loop or iteration construct, you just do it twice.
E.g.
foo.doSomething();
bar.doSomething();

only if you have to push beyond 2 people start to use collections and iterations.
for (Object o: somecollection)
{
o.doSomething();
}

just for 2 objects, no-one bothers to create a collection, they just instantiate two objects.

At least thats what I usually do - and I know others as well.

But - as I said - I experienced the "from 1 to n" problem last weekend - let me elaborate:

In our neighborhood we have a great service that delivers a box of vegetables right to our home.
There's also a website, where you can check this weeks contents of the box.

Unfortunately, though, the site does not offer an RSS feed.
No problem, I just create(d) my own, with a simple job, that runs daily:

1. connect to the site
2. scrape the contents of the site
3. re-format them
4. and put them into a (static) RSS file, hosted on my homepage.

Put that RSS URL into iGoogle and have the contents right there in my personal google portal.

Easy.

Just 2 weeks ago, we decided to have 2 boxes (one with vegetables only, one with vegetables and fruit) on alternating weeks. So I had to re-write my little thing to handle two different "boxes" instead of just one.
(Frankly, I just went for the n-solution, not the 2)

I more or less had to totally re-design the whole hack... About the only thing that remained quite stable was the core RSS handling (through Rome) and the scraping/parsing of the HTML (using HTMLparser).
What I had earlier looked more like a classic C (not C++) program, with almost everything done in main()... I knew it was a bad design... but I did not anticipate the initially.

So, this was a really good lesson for me again, to "design for n" early.