Segway is soooo yesterday (you can tell, they even put up shop in Singapore. The new kid in town is called Orbis Urban Mobility Vehicle

The big differences to the Segway: only one wheel and it is light and foldable.

Now if that one would come in Yellow!
(via Yanko Design

Three years ago Volker published a market share analysis of the smart phone market originally found at Gigaom. The world looked good for Symbian:

Fast forward to now. The US market looks very different now:

as reported by Android Central. The international figures cite 46% Apple, 25% Android and 21% Symbian (I wonder how the figures would look like for the world excluding the US). For example in India the distribution is 93% Symbian and 4% Apple. You can download the whole report (the usual caveats for statistics apply). Windows mobile seems all but to disappear. I wonder what will happen to all the mobile processing devices (like Symbol) that formed the backbone of corporate mobility strategies. Also you need to be clear: a RIM user is much less likely to use her device to surf (due to the comparable pathetic browser) to ad-infested web sites, so both RIM and Nokia might be under represented. At least Nokia tries to

fight back. We live in interesting times.

My friend Michael Sampson reports back from the Salesforce " Dreamforce" conference. In tune with his latest book he enlightens us about user adoption. John McGuigan of Fiberlinks Communication presented The Cardinal Rules of User Adoption:

I absolutely agree that utility trumps any carrot or stick. If a tool helps you to " be more efficient in what you do every day" (Incidentially the Lotus motto) you won't need external motivators but rather traffic management to handle the user rush. A good example are mobile devices. Hardly any organization needs to advertise the use of a smartphone internally. Users want them, want them badly since their perceived advantages are obvious.

Java was a sleeping beauty in Domino land. Looking at the version history:

• Domino 6.x : JVM 1.3
• Domino 7.x : JVM 1.4
• Domino 8.0x : JVM 1.5 a.k.a JVM 5.0
• Domino 8.5x : JVM 6.0
• Domino [some-future-version] : JVM 7.0

If you do anything with Java on Domino check out the IBM performance data

Another reason to stay current with the Domino versions.

The old IT joke goes: "If something is broken, it is always the cable". In our networks the closest you get to a cable is the low level protocol a client (Rich Client or Browser) is using to talk to the server. Some protocol analyzer should be in the bag of tricks of any admin and developer. For low level work there are tools like Wireshark, but they may be a little too deep for our needs. Looking for something simpler you will find Apache TCPMon for monitoring your HTTP traffic (cross-platform, I don't care for single platform tools), but you will be hard pressed to find something to watch your Notes client communication short of with the notes.ini settings CLIENT_CLOCK=1 and DEBUG_CONSOLE=1 and other settings. Enter the power of the R8.x sidebar and the creativity of Keith Smillie. He created a nice sidebar plug-in called RCP Monitor

Once installed it allows you to see exactly what is going on during communication between the Notes client and the Domino server(s). Very educational to watch replication, online access, response times and data volume with and without compression. While you give Domiclipse a visit, check out DocViewer, Repton, DXLExplorer, DXLExporter, DXLImporterand the famous LOLcode editor. Keith includes installation instructions and access to the source code. I haven't tested it on Mac, but it runs well on Linux. Well done!

Fellow IBMer Stefan tweets about a PC Welt article in German titled eMail madness - these are the worst sins in eMail. The article makes an interesting read (Google translate). What I found remarkable is that the author references basic communication theory in the beginning citing the four qualities any communication carries: factual content, relationship, self statement and plea. I learned about these qualities in the works of Schulz von Thun during communication training many years ago. Here are the 7 sins in summary:

1. Subject sin: The subject line is the one line advertisement of your eMail content. If it isn't related to your content or too general you and your receipients won't understand or later on find it. Subject and content need to match. Variations of this sin: pack too many information into one eMail (instead of separate topics), have a blank subject or recycle an old message with a totally unrelated subject line
2. Chain sin: Instead of summarizing the current status the receipent is left with sniffing through a whole chain of messages in the body field. The sin also carries the risk of information leaks: if you add new receipients to the chain they might gain access to information not inteded for them.
3. Ping Pong eMails sin: a rapid sequence of emails between 2 people (and a large audience in the CC list). eMail is inherently asynchronous. If a conversation is needed, the participants should use a phone or a chat client.
4. Avoidance sin: eMails are suitable for notifications and information. They make a poor tool for leadership and decision making - especially when there is dissent what the right course of action is. So using eMails to ask people to do unpleasant actions or announce decisions can be easily used to avoid responsibility, the responsibility to make decisions with the team and based on facts, evidence and leadership
5. Mobile Messaging sin: Using a mobile messaging client mostly cuts the participant off the mail chain, so (s)he might not be fully informed. Only really tough users would download and read any attachments. The (compared to a proper keyboard and regular screen) poor usability leads to very short context deprived eMails, stuff like: "go for it" or "Approved". They leave you wondering what this is all about
6. SMS sin: S stands for short, so don't try to communicate anything more complex than "the train is 30 min late" or "pls. call urgently regarding Project XYZ"
7. Useless guidelines sin: The intranet has eMail guidlines, but nobody cares since they follow the senior execs who are happy sinners. If you want things to change you need to be a role model

You could easily add a few more: the "endless long CC list" sin, the "reply with unchanged attachment" sin, the "everything comes with a return receipt sin" or the "you have to answer in 5 minutes expecation" sin. What are your favorite eMail sins?

You can communicate with IBMers and Lotus professionals using Lotus Sametime. Chris Pepin had published the instructions how to do that long ago. However there is more than this one option.
Update: Thanks for all the comments. I've reformatted and updated the blog post accordingly.

• IBM External Sametime Server: You need to have an IBM id, to get one register online. Once you have it, create a (new) community in your Sametime client (see below). Thereafter lookup your IBMer to add him/her to your buddy list.
  • Server/Port: extst.ibm.com / 80
  • Advantage: You can reach any IBMer using Sametime, surprise them.
  • Disadvantage: Availability is not production level
• BleedYellow: It won't connect you to all IBMers, but to the Lotus community at large. You can register at BleedYellow, a Lotus connections site courtesy of Group Business Software (part of them formerly known as Lotus 911). Once you have your id you not only have Sametime connectivity but also access to a full Lotus connections experience. After authenticating you want to add 2 public groups to your client: "IBMers" and "YellowBleeders". The first gives you access to all IBMers who have registered on BleedYellow, the later to the whole community.
  • Server/Port: im.bleedyellow.com / 1533 or 80
  • Mobile/Web clients: stweb.bleedyellow.com / 80
  • Advantage: More than Sametime, choice of ports, larger Lotus community
  • Disadvantage: Not all IBMers are there
• Lotus Greenhouse: is the test drive site for Lotus products. It allows to testdrive a lot of Lotus' latest software including iNotes, Traveler and Portal. You need to register.
  • Server/Port: sametime.lotus.com / 1533
  • Advantage: As Mark said: lots of IBMers there. One registration to try Lotus stuff
  • Disadvantage: Not a production level environment
• Lotus Live: IBM's cloud offering for collaboration, Lotus Live features eMail, Activities, Files, Contacts, Meetings and IM. You need to be invited, have a trial account or be a subscriber (yes I know: the "buy now" button is missing).
  • Server/Port: im.lotuslive.com / 1533
  • Advantage: Production level environment, great for external communication (I love activities and files)
  • Disadvantage: Ultimately you need a paid account. Not too many IBMer there yet.

One of the unique features in Notes and Domino are form formulas. On a view you can specify a formula that alters the form used to show a form. This is very handy to show the same document reformatted for different stake holders, so they can focus on what is important to them

Form formulas are a tried and tested solution. So I was wondering what happens when you bring XPages into the mix.

With this download speed who would like to use a cloud based application?

The probably most popular category of application build with Lotus Notes and Domino are workflow applications. Those applications need to notify respective users about changes in status and need for user action. In other words they are attentions seekers. Early or simple workflow applications simply used code like @MailSend( DocApprover ; DocRequester ; CentralArchive ; "Request for approval: "+subject ; "Please approve leave as specified in the request from "+docRequester ; Description ; [IncludeDocLink]). eMail wasn't such an annoyance and the world was good. Later more sophisticated approaches using NotesDocument.send were added, but basically the principle stayed the same.
With the raise of alternative notification mechanism more options were added. Today we eventually find notifications using RSS/ATOM, eMail, SMS, Text-To-Voice calls, automatic todos, Tweets or Instant Messaging (I haven't seen a workflow application writing on your Facebook wall so far). All these attention grabbers have in common, that they are part of the application and what I would call "publisher driven". I would like to make the case for a change and suggest an intermediary that takes in all the notifications of all the enterprise applications and lets users decide how and when (and when not to be notified). Since notifications are designed to attract your attention I call this intermediary " Attention central". You could see attention central as precursor or filter for the "river of news" envisioned by IBM's project Vulcan. The interesting difference: it is possible with the Notes and Domino infrastructure you have today.
What properties would such an application have? Here you go:

• Universal Interfaces: Applications can deposit notifications using REST, eMail, SOAP, Sametime or MQ. Libraries for LotusScript, JavaScript, Java and other languages make deposition simple (actually with a REST API any active language can do that)
• Universal delivery: Notifications can be delivered to users via eMail, Sametime (both pull and push), SMS, as RSS/Atom feed, using MQ or being polled through a web service
• Application Profiles: Applications that are allowed to use the service have a profile where the default mechanism for notifications is defined. The profile can specify what channels users can choose from.
• Prioritization: It can be specified in what sequence notifications are delivered. E.g. "use Sametime if user is online, otherwise use email" or "Use Sametime, wait until user is online" or "Use eMail unless OOO is active, then send one summary when back"
• Conditions: Use RSS for normal priority, use Sametime for "urgent"
• User profiles: Not every user would bother, so the user profiles are optional. In a user profile the defaults for the given user can be specified and how they are mapped to application defaults. e.g. "If app default is eMail, send me one summary per day, but notifiy per Sametime if urgent"
• Delegation: Users can specify on an application per application base or as a default if notifications should be delegated. A delegation can be temporary (from/to), or conditional (if OOO is active or this webservice returns true) or permanent (my PA handles all leave requests for my team)
• Transparent: Regardless of notification channel a summary of notifications would be available via ATOM/RSS and on the main site
• Transient: Notifications that have served their purpose would be removed from plain view (that might need some adjustments in the participating applications)
• Integrated: The UI (profiles and notifications) are available a component for composite applications or iWidget integration. Workflow applications can make the notification settings part of their own UI without actually storing them other than in Attention Central
• Distinct: Applications that call the API can specify what quality the notification has: progress report, completion, action request etc. This information can be used to define notification channels

Once you get the general idea the list of ideas will grow. Definitely it will allow to manage the stream of attention and action demands more effectively. To be clear: The application would handle notifications only. It wouldn't grant access or perform workflow steps or anything else since this would require too deep changes in your existing workflow architectures. Also the hallmark of flexible application architectures is: one module, one task. Of course you might end up with your deputy getting notifications of events where the originating system doesn't allow access. But that is already the case today if you just give your deputy access to your inbox, so Attention Central doesn't degrade from what you have now.

For mere mortals: ask a SeatGuru before picking your seat.

It turned out a lot of my Blackberry Blues was mainly based on faulty settings on the side of Starhub. They work very hard to dampen my confidence in them. From my inbox:

Dear Stephan,

Congratulations! Your StarHub Hub ID *myid* has been activated with FREE
StarHub Wireless Broadband service.

You can now use your Hub ID and password to access StarHub Wireless Broadband
service at any of our 300 hotspots
islandwide and other partner hotspots
(locally and overseas).

For wireless access at any partners hotspot, you will be charged on a
pay-as-you-use basis and any applicable usage charges will be billed to your
StarHub Digital Cable or MaxOnline account with effect from today.

For more information on StarHub Wireless Broadband, click here.

Yours sincerely,
Hub ID Management
StarHub

Pretty neat, good customer service. Unless of course you try to follow any of that links. The are ALL broken. I do understand that from time to time you want to reorganize your web site and links change, but I side with Jakob Nielsen: Links need to live forever (12 years ago!!!!). It is plain lazyness to use the 404 redirect to the main page after a website redesign, especially once you sent out relevant links like billing information pages that people use for referenence. How hard would it be to maintain a list of old urls (before the re-design) and map them to new urls (after the re-design) and then in your 404 page either auto-redirect or have the page up long enough so people can take note or update their bookmarks?

And it is sloppy governance to upgrade your website without upgrading the links your automated systems use.
Update

Activities are my favorite component in Lotus Connections. Firstly they let get my team (which changes from task to task) and myself things done. Secondly it is available offline. In my part of the world* "always on" is not a reality. It is more "mostly on, but with horrible latency and low network predictability or realiability". So working online is quite often frustrating. I like the model "work offline but with a background sync" much better since it fits reality. Push mail works that way and more and more apps (push apps (?)) do the same. Of course sometimes looking at the sync bar is scary.


* here: all of AP. Quality differs widely.

Domino Server 8.5.x is available on a lot of platforms in a lot of versions:

1. Linux for z/OS - 64 Bit
2. Linux on Intel - 32 Bit (runs well on 64 Bit OS)
3. Solaris - 32 Bit (runs well on 64 Bit OS)
4. System i - 128 Bit
5. System p - 64 Bit (32 if you ask very nicely)
6. Windows Server 2003-2008 - 32 Bit (also can run on 64 Bit OS)
7. Windows Server 2003-2008 - 64 Bit

What is obviously missing is a 64 Bit version for Linux on Intel (Linux here means: Redhat or Suse, Ubuntu isn't on the official server list [yet?]). Technically is isn't a problem since IBM has a 64Bit Linux version running. It boils down to customer demand and support cost. Every additional platform increases support effort (translated: fixes take longer). Occasionally IBM drops platforms from future versions of Domino (like: Netware, OS/2 or HP/UX).

So I'm wondering:
What would happen if IBM drops -in a future version- support for 32Bit Linux in favour of 64Bit Linux?
Would that be an issue in 201x? What's your take?

To make this crystal clear: This is me wondering, this is not any official IBM inquiry or a disclosure of any IBM plans.

Charlene Li of Forrester research outlines six items to constitute a corporate blogging policy:

1. Make it clear that the views expressed in the blog are yours alone and do not necessarily represent the views of your employer.
2. Respect the company’s confidentiality and proprietary information.
3. Ask your manager if you have any questions about what is appropriate to include in your blog.
4. Be respectful to the company, employees, customers, partners, and competitors.
5. Understand when the company asks that topics not be discussed for confidentiality or legal compliance reasons.
6. Ensure that your blogging activity does not interfere with your work commitments.

The Wiki page contains a set of links to examples of published corporate policies including IBM's Social Computing guidelines

While answering a question on StackOverflow I had to retrieve Domino's URL sytax. Here are the essential links:

• The official IBM documentation (a.k.a the Help file)
  It has the published list of commands for databases, views, forms, document, settings
• The "official" IBM cheat sheet (and article about R6, but still valid)
• DeveloperWorks article explaining search URLs
• Additional commands courtesy of Carl Tyler
  Carl documented the ?OpenFIeld command to read naked RichText content: http(s)://yourserver/yourdatabase/view_or_folder/document/Body(or any other RT Field)?OpenField

Armonk (NY) / Mountain View (CA) IBM and Google today issued a joint statement to make the Internet of things a reality (The Internet of things, in short, is the capturing of real world physical data to be processed - mostly including location data - for analysis and augmented reality). Effective today they form the Internet of Things Alliance (ITA). A Google spokes woman summed it up: " We will merge Google's network infrastructure with IBM's Smarter Planet know how to make the Internet of things become reality".
If you ever wondered why Google was buying up dark fibre you now have the answer. According to sources they are in the final round of negotiations to take over the site www.ita.org from its current owner Mr. Lasky for an undisclosed sum. Lasky will serve on the board of the alliance as its first chairman.