Today we have mobile, jQuery, Dojo, Meteor, HTML5, CommonJS, NodeJS, XPages and many other tools, however the fundamentals for a good web application I worked out 12 years ago are still the same:

We just need to keep them in mind.

My friend Jonathan Wong published an article on infopier.sg titled " Understanding the Needs of the Next Generation Digital Consumer". In it he describes the three core needs of the digital consumer. I 100% second his point of view and would summarize it with this little graphic:

Culture eats strategy for lunch is all the rave in #SocBiz land and it tops the 10 top tips from Sandy Carter. When your culture is about careful nurturing and grooming, this is for you:
Social Business is like a tree. It needs to grow healthy roots and its crown needs to be balanced to sustain.

Bliss is being a gardener.

In the brave new world of social file sharing HTTP(s) has won. From the humble webDAV specification to Sharepoint, IBM Connections, Dropbox, UbuntuOne or the emerging industry standard CMIS all use HTTPs to access files on the backends. Since HTTP(s) is the first thing that is available when a network connection is possible and quite often (especially in public hotspots) the only thing available, this success isn't surprising
The more venerable protocols like CIFS (a.k.a. SMB), NFS or SSHFS didn't stand a chance since (rightly?) security experts block them on the corporate firewalls to prevent data leakages.
A lot of times the HTTP integration uses basic authentication, that is hazardous on HTTP, but OK on HTTPs. However providing applications with username and password makes it an update nightmare. Therefore OAuth became rapidly popular. But every fix for a problem comes with its own challenges. The challenge here is OAuth session expiry. While this is hardly an issue getting your latest tweets (140 char transmit in less that 30sec if if you only have 10 Byte/sec), is is an issue for large files.
An open bug in UbuntuOne explains it nicely: " OAuth headers used to check the validity of the request contain the timestamp of the request to prevent reply attacks .... for requests taking less than 15 minutes (the default for oauth in updown). ". If 15 min is the default you need a lot of bandwidth depending on your file size:

• 9 kb/sec for 1 MB
• 217 kb/sec for 25MB
• 870 kb/sec for 100 MB

(That's effective bandwidth, not advertised one). Of course: you don't want to wait 15 minutes for a file, so your real bandwidth requirement might be actually much higher. And that's also the reason why online access to file sharing is nothing more than a band-aid, sync is the way to go.

Martin Luther (the original) famously stated " man muss dem Volk aufs Maul schauen" (roughly translated: " you have to watch how people talk". What worked for a bible translation also works in IT.
While it is nice to have some documentation, quite often it is inaccurate, incomplete, outdated, factual wrong or simply missing. So listening to "how applications speak" is an essential skill, mentioned here before. In this little weekend project these skills get applied to Lotus Traveler. These are our ingredients:

1. Domino server with installed Traveler listening on http Port 80 (https won't do). Also make sure that compression is switched off in the internet site document for traveler, it's no fun to watch gzip encoded data
2. Apache TCPMon installed and listening on port 8888 in proxy mode
3. The Android SDK, installed with an Android device emulator. Alternative: a physical Android device (and your ports open on your machine)

We will configure the Android to use the PC as the proxy and then install Lotus Traveler and sync data. TCPMon will show us what's on the wire (Windows user could use Fiddler as alternative to TCPMon. Let's get started:

1. TCPMon needs to be configured in Proxy mode.
   
   You can test if that is working by pointing your browser's proxy setting to 127.0.0.1:8888. Note: you need the real IP in the Android phone or emulator. The TCPMon screen then nicely shows the outgoing requests and incoming responses:
   
2. Time to configure an Android emulator. After installing the Android SDK you can launch tools/android from the install directory to download and install the various versions of the Android OS Emulations from 1.0 all the way to 4.0.3. In the Tools menu you can manage your AVD (Android Virtual Devices) and configure different images. The emulator comes with the option of snapshots, quickstart, cold boot etc.
   
   I found the 4.0.3 devices substantially slower than the 2.3.x devices, which might be based on the higher default screen resolution. Once you have configured the AVD, you could start it directly from the menu
3. However starting an AVD from the command line is much more practical, since it allows for a lot of parameters. Most notably the ability to cold-boot and the ability to define a proxy or even dump the whole TCP conversation into a dump file. So I started my AVDs with
   android-sdk-linux/tools/emulator -avd MyPhone -http-proxy 192.168.88.170:8888 and
   android-sdk-linux/tools/emulator -avd IcecreamPhone -http-proxy 192.168.88.170:8888 resulting in
   
4. Along the way I encountered a few odities: some of the commands would ignore the proxy parameter and try to reach out directly. I got that sorted out by configuring the device to use the proxy in the access point settings.
   
   (Don't forget to use Menu - save when changing this). Important here is to clear out username, password and server which have a one character value. For a reason beyond my comprehension the initial configuration of traveler would not work with any proxy setting - could be the TCPMon here, with Fiddler it might work - so after downloading the installer, run the installer and download traveler I had to switch off both proxy settings for the initial configuration. The AMD can be just terminated and then called without the proxy parameter and it would resume where it left off
5. Make sure to have the proxy back in the HTTP stream to watch what is happening. It is quite enlightening
6. The first thing once the new device is ready is a request to fetch the configuration which against the current fashion is delivered as XML document that very closely resembles DXL. The request looks like this:
   GET http://yourtravelerserver:80/servlet/traveler?action=getConfig&deviceId=Android_somedeviceid HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
   Host: yourtravelerserver:80
   Connection: Keep-Alive
   User-Agent: Lotus Traveler Android 8.5.2.1
   Authorization: Basic Base64EncodedUserNamePassword=
7. Then you can go on and watch the initial sync happening. To understand what device and server are talking to each other, you need to ask OMA, there the best documentation is available - you might have guessed: Traveler on Android is using SyncML. You can learn how "push" actually works

Next stop: repeat the above on a Mac. On the Mac Traveler uses ActiveSync, so you need to look elsewhere for the documentation. I'll share more about the protocols and findings in future posts (just hope it is raining again on a weekend here).

One of the things I'm interested in after hours (challenge: what are my after hours) is personal well being and fitness. Since I love technology too I have the geeks view. When surfing at Amazon I came across Fitness for Geeks: Real Science, Great Nutrition, and Good Health and added it to my wishlist.
Opening my mailbox this morning I got pleasantly surprised:

Ulrich Krause said thank you, so I say: Thank you Ulrich!

In a recent chat on the supersecret XPages </bitching><doing> chat Mark Hughes contributed an invaluable 3 liner, too good to miss. I added the 4th one:

• You pay someone by the hour, they take longer than if you paid them for the job
• You pay them by the job and it will get rushed
• You pay them a salary and they dont care if it gets done
• You unleash their passion for the task - you get results

While " Death by Powerpoint" is is talk of the town and Prof. Tufte is all against it

the alternatives are not without risks. As a colleague put it nicely: " Prezi is a presentation tool perfectly capable of making your audience sea sick". Presentation tools used wrongly leave you the choice between nausea and unconciousness. In case you haven't seen prezi before: it is a Flash/Air based tool, that allows to create non-linear presentations that swifle, zoom and rotate through your materials: the cadence of Powerpoint replaced by a visual roller coaster.
Working with it for a while I recognized that there are certain interaction/animation pattern that work well to convey a specific message:

• Zoom in and out: Going from the big picture into the details. E.g. you could state an agument and then zoom in to prove it. Same applies to keywords and explanations
• Move linear beween equal sized items: lay out related items and aspects of a topic (often after zooming in). Try to make vertical and horizontal moves not zig-zag and diagonal
• Rotate around a centre: Reinforce a central topic you rotate around. The mental model here: add spokes to your hub argument to create a wheel (= rounded argument)
• Swifel slides: Look at the same topic from a different view point, audience or vantage point. It is like different people look at an object from different angles
• Follow a path: You select a "big picture" as background (a mountain, a road, a plant etc.). You map out your argument along a visible line of that background. It conveys the message "follow my line of argument"

Following these make your presentations more impactful, nevertheless you need to pay attention avoiding nausea. Interactions that negatively influence impact are: wild swiveling, zoom without master/detail relations or zig-zag movements. You still have to work out your message and the visuals. Of course: once you "got" the rules, you are free to break them.
As usual YMMV