Preparing for my June adventure, I'm tracking my cycling progress. So far I tried Endomondo, RunKeeper and had a look at Strava. They all have their ups and downs:

• Endomondo doesn't provide a open data API and I never got the live broadcast working, but the UI is readable on a bike
• RunKeeper UI is too tiny for cycling mount, but live broadcast works nicely and the data API is open
• Strava doesn't seem to provide live updates, but rather tracking after the tour
• Battery live sucks for all of them

A cycling screen (quite close to what Endomondo does) ideally could look like this:

The big numbers are augmented with subtle hints on median performance using a bar display. Would be nice to see an app like that

The first programming language I learned was COBOL both using a Microfocus compiler (with an innovative tool called Animator, today commonly refered to as "Source level debugger") and on an IBM System /36. Until today I think Cobol is cool, not at least since you can reuse its source code, read aloud, as tranquiliser and only in COBOL this compiles without error:
PERFORM makemoney UNTIL rich.
You have to read "full stop" at the end to get all COBOL nuts laughing, because when you missed it, the compiler would mess up (they guy who invented automatic semicolon insertion in JavaScript must have been traumatised by that).
After that dBase, Clipper, Foxpro followed and soon VisualBasic. My early dBase very much looked like a COBOL program, while you could discover both dBase and COBOL thinking in my VB and LotusScript.
It is actually fun to look at source code and guess what was the previous language of the coder. It takes quite a while until old habits do die.
In case of COBOL, they never do, since we cleverly camouflaged the DATA DIVISION. as XML Schema to retain thinking in structured, hierarchical data.
So when you look at moving your applications to XPages, as a classical Domino developer, you are faces with quite some challenge:

A common approach for skill acquisition is to entrust the very first introduction to a training or coaching session, in the vague hope that everything will sort out, right at the beginning. IMHO that is a waste of everybody's time, once a language or platform has been established for a while.
It is like signing up for a "Business Chinese conversations" class when you haven't mastered a single word yet (In case you want to learn Chinese, check out Chineasy).
A more sensible approach is to work through the basics and then discuss with a trainer or coach the best approach. This holds especially true in XPages, where some of the advanced stuff (ExtLib and beans, to name two) make development so much more easy, but scare off the novice developer.
So with 40h of video (yes, that's a whole work week - for normal mortals, for geeks, that's until Tue evening) there is little reason to join a class blank and slow everybody down.
Most developers I guided towards XPages had to (re)learn the mobile interaction patterns and the idea of a stateful web server (a.k.a JSF - not this JSF disaster).
The fastest transition to XPages and mobile apps happen, when the developers spend time on their own with the core platform, to then cross their swords with experienced designers. That's how it is done - so say we all.

Creating output from your objects is a never ending story. In XPages we use Expression Language, in classic Notes forms (including $$ViewTemplates). For the JavaScript front-end developers there is an ever growing selection and there's the good old String concatenation. On the JavaScript side I like AngularJS and Mustache.
The big question with templating is: how much logic should go into the template. Mustache is one of the logic-less approaches that expects most of the logic to be presented by the controller. Logic is limited to repeats for collections and conditional rendering if a element is there or not. I like Mustache, because it is polyglot and can be used in more than one language. The creator of the Java version is Sam Spullara who has a nice explanation on Mustache logic-less, so go and read it. Being logic-less reduces the temptation to break the MVC pattern.
Mentioning "view" always draws the mental picture of a User Interface (with access to an controller), but there are other use cases: generating a report or transforming one source code into another. I like to do these activities using XSLT (Come and see that in action next week) when the result is XML (including HTML), but that approach is not suitable when the outcome would be mainly plain text. Mustache makes that task very easy: Create a sample file and then replace the sample data with {{variables}}.
So I was looking how to apply that for XPages. The sample template is rather simple - more useful templates are subject to later posts:

Test Result
Class: {{.}}
Form: {{form}}
Fields:
{{#fields}}
{{fieldName}}, {{fieldType}} {{#multiValue}}, Multivalue {{/multiValue}}
{{/fields}}

The interesting part is the Java component. With a small helper I extract the fields from a form (from an On Disk Project) and render the result. You could generate custom XPages out of existing forms, or generate data Objects to bind to (instead of binding to a document directly. You can generate reports. There's no limit for ideas (actually there is still the 86400 seconds/day limit ). My helpers look like this:

package com.notessensei.domistache;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import com.github.mustachejava.DefaultMustacheFactory;
import com.github.mustachejava.Mustache;
import com.github.mustachejava.MustacheFactory;

public class CommandLine {

 public static void main(String[] args) throws IOException {
  if (args.length < 3) {
   System.out.println("Usage: domistache DXLSource template output");
   System.exit(1);
  }

  CommandLine cl = new CommandLine(args[0], args[1], args[2]);
  cl.convert();
  System.out.println("Done!");

 }

 private final String sourceName;
 private final String outputName;
 private final String templateName;

 public CommandLine(String sourceName, String templateName, String outputName) {
  this.sourceName = sourceName;
  this.templateName = templateName;
  this.outputName = outputName;
 }

 public void convert() throws IOException {
  File source = new File(this.sourceName);
  File target = new File(this.outputName);
  File template = new File(this.templateName);

  InputStream templateStream = new FileInputStream(template);
  InputStream sourceStream = new FileInputStream(source);
  OutputStream out = new FileOutputStream(target);

  CoreConverter core = new CoreConverter(this.getTemplate(templateStream));
  FormConverter form = new FormConverter(sourceStream);

  form.convert(core, out);

  sourceStream.close();
  templateStream.close();
  out.close();
 }

 private Mustache getTemplate(InputStream in) {
  BufferedReader r = new BufferedReader(new InputStreamReader(in));
  MustacheFactory mf = new DefaultMustacheFactory();
  return mf.compile(r, "template");
 }
}

Einstein is attributed with a famous quote: " Everything should be made as simple as possible, but no simpler." (called Einstein's razor, the counter balance to Occam's razor). Looking at the social software landscape today I must conclude that it is both too simple and not as simple as possible.

• In the "too simple" camp with have the notion: "everything is just one big stream of collaboration and a few tags will do" (and it's variations). If you follow this notion all collaboration you would ever need is a Twitter stream or a Whatsapp group.
• On the other hand "not simple enough" means: there are appropriate tools for every purpose: Blogs, micro-blogs, status updates, walls, file sharing, link sharing, activities, communities, team rooms, mailing lists, persistent chats and what have you

Neither of them fits the bill. The simple approach makes it easy to contribute (Express your live in 140 characters or less), but hard to structure and retain, the complex approach allows good structure, puts information in context, thus easier to find (again), but burdens users with decisions what tool to use when it isn't yet certain what's the most appropriate, resulting in anxiety or flat out rejection (" too complicated").
So something sharp is needed, lets get Occam and Einstein to work. Step 1 is to go meta and have a look how social collaboration contribution mechanics actually works:


Several triggers can induce a contribution to collaboration. The list of usual suspects include email, all known social tools, but also thoughts, business processes and face to face interactions. In summary: anything that is brought to or catches our attention. As technologist we gravitate toward the tool to classify the triggers, rather than the motivation behind them (as if it is more important how you arrived at the cinema that how good the movie is you are about to watch. Exactly here lie the adoption woes organisations face: bickering over tools instead of focus on intentions and outcome.
The interesting aspect in the illustration above is the word Meta. Thanks to friends who protect us the word Meta has gotten much deserved attention. I think a clever handling of meta information is the holy grail of social computing. Data today are commonly: date/time, author, tags (eventually), place of contribution (blog, wiki, Status update etc), size and supporting files (if any). However meta data goes further

There are 2 aspects that need to change in todays meta data - One: removal of the creator's burden to decide where to publish upfront, so (s)he can focus on the contribution. Two: the ability of the target audience to define more of that meta data as insights arise. IBM is on the trajectory to let the machine contribute to data and meta data too.
I advocated better sharing before, but I see more convergence and conversion needed:

• The "where" of a contribution is only an attribute, so I can "change" a blog entry into a WIKI by adding additional data (where in the Wiki page tree it should show)
• A Wiki can have a time line like a blog, there is no difference
• When I share a status update that contains a link, that link becomes a bookmark (unless I tell it not to)
• Readers of my contribution not only can comment or share my entry, but add meta data, including the ability to determine: this should be on this wiki page (as example)
• Flagging customers, people and processes
• A better overview with filters for my contribution
• Access to a shared and personal taxonomy
• ... there probably is more

All this required to transit from a tool centric to a contribution centric point of view.
As usual: YMMV