thingamy

open document standards

I'm scratching my head over the "standardisation" process for document file formats, in particular the text and form documents. Open Document Format and Office Open XML pitched against each other at Ecma, much time and resources spent.

Why bother at all?

A form or a document consists of two things - content and layout. Nay, many pieces of content and then layout. Information mashed up into one, a text document or a text form. An information storage and distribution methodology more or less unchanged since the days of the Pharaohs. Papyrus scrolls, Gutenberg prints or OOXML formats - same stuff, new wrapping.

Quite practical in pre-IT days, but it has a drawback: The moment you manipulate data it loses value and is harder to find, link and reuse. Storing data in manipulated form is simply put, not smart. Nope, it's plainly stupid if alternatives exists.

A letter contains finite information objects, each easily stored using some good old IT standard, say ASCII.
It has a body text, something that could easily be split in finite objects like Introduction, Argument, Closing and whatever you'd like - just name the objects and define the relationships.

And then it has an Address, certainly a finite object if there ever was one. How many "documents" has your address on it? Hundreds? Thousands? How many misspells would there be within that mass? Tens? Hundreds? How many letters do you have to send out when you move? Hundreds? How many letters have never reached you?

Why not have one single "address" object representing that house then linked to any other information object pertaining to the house or you as long as you live in that physical object? One single link to update, no room for errors, no mess.

For textual information I am not interested in stored layout, layout I can apply when I need it thank you. I'm interested in pure information. And most probably a single data object therein and of course how and what it links to.

A "Patient Journal" is a more elaborate "text form" but it consists of finite objects that arises at separate occasions - an inoculation, a surgery, a round of medication, a broken arm. And truth be said the health industry would be better off with finite objects than the form - thus researches can be allowed to see whatever they should see but not more without signing an NDA.

If I want to send a letter, if I need a report to be distributed, if I need a patient journal to be studied in it's entirety I simply apply some logic to the finite objects; start with this object, then add that, then those - and print it out with nice margins and the font of the day.

Keep data in raw form, apply logic when needed, never save manipulated data. Full stop.

Stop this "text document" and "text form" thinking now, time to move onward from the papyrus-scroll-concept and stop bothering with standards for manipulated data. That is bad form and quite foolish. 

software design and asking questions

We ask questions when we want to make the world better.

Like when we want to use less resources, become better, earn more money - or when we want to help a customer to do any or all of the above and thus be able to deliver a product or service.

The software designer asks the questions of the customer and creates a product to deliver an answer.

But...

We ask "how" too often:

How can I communicate better?
How can I gain more knowledge about my customers?
How can I control my resource use better?

That would lead to better PIMs, word processors, CRM and ERP systems. A safe but slower and slower incremental path to a better and more profitable future for our customers.

We should ask "why" more often:

Why do I need to communicate?
Why do I have those customers?
Why do I use those resources?

That could lead to better processes and less communication, it could lead to better values offered and more customers, and it could lead to a revisit to the strategy and a better business model. Risk is higher but so is the chance for quantum leaps to a better world and higher profits for our customers.

The core of the "how-software" is given and the focus is on user interface, speed and delivery.
The "why-software" will require process as a core and flexibility as framework, a much more daunting task.

I think that software should support the "why"s.

objective vs subjective (dysfunctional software)

Once upon time, when I was an investment banker I often found myself in a group of 14 around some conference table.
The routine was amazingly similar for such gatherings - somebody distributed annual reports, accounts or financial spreadsheets. That's when you could see 14 HP 12cs (financial calculators) being whipped out simultaneously. Pencil at ready, 14 souls threw themselves at the task of extracting real data from the manipulated numbers, then adding their own logic.
Soon you would hear 14 sets of arguments why their logic was right and how it played into their interests - lower price, higher price. And the day passed with bad coffee and messy sandwiches.

And history, history comes to us via someone. To understand the reality we compare documents, stories and images and try our best to read between the lines. Just like investment bankers, trying to find a nugget, or at least something useful.

Extracting reality from subjective writing. Shaving off iffy logic from manipulated data.

Why do we always use, save, produce and present manipulated data, why don't we stick to raw data and apply logic to the data only when needed?

Because "forms, documents, books, stories, poems and songs" was the only solution when we only had pen and paper and not even that to capture events for the future.

The persons that events happens to usually perish over time. Become history. Thus event documentation.

Then software came and copied that method (how silly!), so now we have:

Event and transaction driven BPxx and ERP process systems that produces subjective event documentation; forms and documents. Funny thing, the objects the events and transactions happens to does not perish in a system, still only events are documented. Hmmm.

Word-processors, accounting, etc. - applications that save manipulated data, subjective results.

But we gained one thing with IT: We're now able to produce more documents at a faster pace. Great, now we have to shave off the logic of 26 different numbers instead of three numbers. Now we have 34 event reports to represent the thing it happened to. Plus the thing itself of course. A folder of 35 documents to represent one thing. Hmmm.

Hello reconciliation, hello errors, hello confusion.

Sisyphus would have felt at home. Nah, he would have been confused when he could not find the boulder he was supposed to push, only a stack of reports from each time it rolled back down the mountain.

tinker or flow

Dennis had a post yesterday at ZDNet that got me thinking, not the way he wanted me to think... of course, but Dennis expects that :)

He mentioned thingamy which he described as "lets businesses composite business models pretty much any way they choose." then "A nice idea if you've got business modelling skills but not so good if you're a smaller business."

I know Dennis would like some templates to take some of the modelling part out of the equation - make life easier for the hard-pressed small business owner.

And I concur - having templates for thingamy, just like you can download templates for Excel, would be nice, a kind of library of "applications". But...

Only yesterday I said that "flow is everything", and I mean it.

Applications are like workstations in our hobby woodworking set-ups in the garage - a place where we love to tinker with one piece of wood and get the immense satisfaction in seeing it change and develop.

I see the same when using Keynote / PowerPoint - little tweaks, add an image, tweak again, lean back and furrow my brows, dip into it again... and the hours flies satisfactory.

Or when writing a report, a dash content then layout, layout and more layout tweaks, then some small rewrites and more layout tweaks.

Not to talk about the mere joy of messing around with some spreadsheets, pure joy.

We like to tinker, it's instant gratification.

We're in a state of "flow".

Albeit a self-indulging flow. Not much overall efficiency going on there, excellent little snippets of creations yes, but total value creation for the client? Not really, that requires a more holistic flow.

Take a look at Microsoft's presentation of Vista at CES the other day - "here you can instantly change the image inside Word, awesome!", "see, the desktop background can be live, amazing!". The main office workspace now having added tons of new tempting ways for self-indulgence... cool.

With the head deep down in the intricacies of a spreadsheet or the colours of a slide we do not see much of the whole issue. The whys, the ultimate value to be delivered, the reasons for doing business at all - are such in focus when you're in the margin-tweaking-and-font-choosing flow of the letter writing?

Nope, guess not. And that's not good for business.

And as business is a flow, nothing but a flow, a holistic flow also called the Business Model - that should be the focus.

When you click on your Outlook or Calendar you start a one-event-flow, a meeting. Hardly a flow.
But that single event is always a part of a bigger flow, a flow that is important for the well-being of your business. What happens prior to the meeting? What's the reason? What happens after? A report to be written, then sent to somebody else who will then add some or decide what to do next? An offer to be created and sent?

Applications delivers limited personal flows, space for self-indulgence, they simply do not deliver holistic flows, natural business flows - the stuff that is the reason for doing business at all.

And Dennis, even small business owners knows their holistic flow - they know their Business Model! Thus they are business modellers on a daily basis.

But they cannot do that easy using the "workstation-applications".

That's why I drag my feet on templates, that is why I'm trying to offer a tool that can entice and give satisfaction beyond tweaking layout and choosing fonts.

It is fun to tweak business models and choose paths in a real business flow!

That is my favourite pastime, thinking about how to do stuff better, how to smoothen the flow, how to help my customers - on my bike, on my skis, in the shower.

Why not bring that joy into the workplace? And that is not a rhetorical question ;)

thingamy manifesto

In these day of New Year Resolutions, Five Things You Do Not Know About Me and Hugh’s rapidly increasing list of Manifests I crumbled under pressure (thanks Hugh!).

Actually, manifesto? Well, more like a summary of reasons why we’re doing the thingamy:

1. The Organisational Hierarchy is kaput - as single purpose executor of the Business Model it requires reorganisation every time you need to get better, an utterly futile exercise most of the time. Replace it.

(Some more here, here, here and here.)

2. Managing is a waste of time. Leadership I need, getting out of bed in the morning I can do myself.

(More here, here, here, and here.)

3. Legacy software models the "way we always did things" - usually a model from the days of paper, quills and desks. Model reality instead.

(More here, here, here, here and here.)

4. Tree-structures are faulty. "Where it resides" is only two dimensional and suitable only for places. Use tags and any other means to enhance the knowledge and make finding easier.

(More  here, here, here and here.)

5. A report is simply logic applied to raw data. Apply when needed and keep all data in raw form. That will do away with applications, middleware, complexity and deliver far better reports.

(More here, here, here and here.)

6. Accounting was “invented” in 1573 1494 using paper and quills, dump it and let the IT system that delivers the flows capture the real data and display it any way you want real-time.

(More here.)

7. Budgets are completely silly. You know nothing about the future so forget it and leave such to soothsayers and magicians.

(More here.)

8. Think of processes as "what happens to things", not "what things happen".

(More here and here.)

9. Documents and forms are bad - they only document "what things happen" creating reconciliation, errors and rigid processes. Let the thing itself capture what happens to it.

(More here.)

10. Process is not a track, it's a football game where you see the goal and look for and try openings all the time. The ball is the flow.

(More here, here and here.)

11. Flow is everything - flow is relationship, flow is knowledge, flow is context and flow creates value. Your business is all about flows, never forget it. Build the flows, then better the flows to better the value and your margins. Do it, then do it again, then do it more. Think extreme Business Planning.

(More here, here, here, here and here.)

Here's an earlier twist to the issues if you care - You Know Something Is Wrong :)

software - big and small

Noted that Microsoft is coming out with a software update to make the Zune compatible with Vista. Good for them.

The patch is 22 Mb.

Thingamy is 14 Mb.

With Zune you can play some music, with thingamy you can run Microsoft.

Are they paid by line-of-code in Seattle?

waterfall vs agile

JP says he's been quiet for a bit. Good for us because when he's back, it's with a bang!

Go read this, for me nicely summed up with:

"Using Agile, you feel insecure (-ish, especially if you’ve not tried it before) at the start of a project, and satisfied at the end. Using Waterfall you feel good at the start and crap at the end. If there is an end."

Actually, kind of puzzling that waterfall method for software implementation / development still exist - software is after all a model of something:

A 1:32 scale model of "QE II" or a "Ferarri Dino" and I would have no problem with waterfall.

But software models something truly iffy - human behaviour included. Modelling it would be more like art - a representation of reality enhancing the important issues and downplaying the not-so-important details dynamically changing as it moves forward towards completion.

I would not think an artist would ever contemplate waterfall... Jasper Johns do sum up his reality nicely.

user friendliness, part one, the semantics

Wow!

Must say putting out the demo video was worth it, thanks all for bothering to look at it and to those who have given excellent (and... eh... well deserved and not unexpected) feed-back!

Some quotes from yesterday's post here and at Gapingvoid:

"I would say that the naming of the categories is key. For example, the word stack had no meaning for me.... usage can be made even more intuitive by choosing category names and indeed icons that facilitate immediate understanding" John here.

"...this was the geekiest demo I've ever seen...  I couldn't easily follow most of what was going on during the workflow build... Now you just sprinkle some Kathy-Sierra-Dust on it..." Tiago here.

"Y'all might think about changing 'language' (Google is very good at using 'humanspeak' for their components) around the components. Like, most people think 'string' means what the cat plays with. And variable? Nobody should have a consumer-facing product with the words string, variable, etc. in it... Classes, containers, tags? Yikes." Tara here.

Folks, I bow to the wisdom, appreciate the kick in the butt and have put on thinking cap.

Semantics are not as easy as I thought it would be, this is after all not a run-on-every computer at every home kind of product. It is a server based system to run your business with very limited access to the "builder" interfaces (which the demo was all in). No excuse, but my competitor's work-flows looks like this:

Kindly borrowed from here, go and read, hilarious stuff!

Or what about the settings for a Work-flow action below (from same article), then "string" and "class" seems rather user friendly :)

Suspect they would not get far building anything from scratch in 15 minutes...

Back to the semantics - the hard bit is of course to be easy to understand while not loosing any precision.

Question will often be - do you need any kind of semantic introduction/training or not? Any semantic "hooks" in daily life that can be used without loosing meaning?

The art of sailing has a semantic threshold: Port, starboard, sheet, clew, cleat and guy. Port is not left, it's the left side of the vessel when looking forward. Sheet is not a rope, it is a rope fastened to the lower leeward clew of a sail.

Do business model and process modeling have a semantic threshold? Yes. Will it have it in the future? Dunno. Will a system (that delivers on all other levels) without that threshold have a boat length or two on the others? Yes, there I agree fully.

So there you go, thinking cap on, sleeves rolled up, will be back - I do love a challenge!

[UPDATE: Thanks to all your great comments and general well deserved kicks in the butt we will now go into a period of "feature freeze" and focus on exactly these issues - usability, semantics, layout and whatnot - goal is "No Manual" and a thumbs up from Tara (have to set high goals or what?). Ah, that felt good to get off my chest ;)]

documents, schmocuments and Pluto (more about thingamy)

I really dislike the terms "documents", "forms" and "files". And "planets".

Sources of missed opportunities. Instigators of late evenings at the office. The mothers of all bounced mails. The source of unimportant academic discussions with no end.

Is Pluto a planet?

Who cares unless you must categorise, position it, tree-structure it? But as pigeonholing is the preferred way... then we have to care.

Even for "information", stuff you cannot sit on, we still end up using the same method. We cheat and imagine information as "documents" or "forms", finite stand-alone objects, which makes tree-structuring / categorising / pigeonholing possible.

Thus your address have to be copied onto your Health Records, your Insurance Contract, your other... eh... forms. Then those copies have to be maintained and updated with great care.

Thus last month's sales figures will be constructed from the accounts (more or less, depending on efficiency of the post office), from a sales report, from a spreadsheet somebody did the other day, from  yet another spreadsheet somebody else did another day and from...

Hello end-of-month reconciliation headaches, hello mailing lists when moving. Hello never being quite sure everything is right in a dynamic world.

Multiple "data" objects pretending to represent one single real world object? That never worked, and it will never work.

Consequently "forms" and "documents" should be a thing of the (paper-based) past. Full stop.

That's why we do not use tree-structures in thingamy. Nor do we use "forms" or "documents".

We chop stuff and information up into smallest possible objects so no real world object need to be represented by more than one single data-object; one single address object that is "related" to your bank accounts, your employment contract, to... you. And to your spouse, your children, your dog, the property developer, the insurance company, the...

Then we use more than one method, in combination or alone, to describe such relationships ensuring that we can use the objects in meaningful ways later in any way possible:

Object built from objects: Very precise, very inflexible. A bike-object is built of precise numbers of unique objects like a frame, wheels, a handlebar...
Thingamy can build classes (the cookie cutter to stamp out unique objects) using any type of property and/or other objects.

Tags (use of multiple tags, otherwise it would be categorising): Very generic, can be used for anything, could be all-encompassing but for one reason - it requires some discipline to get precise results in a hurry. Thingamy has a tag-browsing bar (see image) that can be used in any interface, report or even in the midst of a task.

Links: Quite generic and very precise, but sometimes too structured. Perfect for iffy objects like persons. In fact a person does not even have to be an object - just a cloud of linked objects; address, medication objects, bank accounts, children...
And the links are bidirectional: Choose an address object and you'll find everyone living there, who lived there, who built it, the insurer, you know. Link or unlink objects at any time.

Containers: OK, granted that tree structures cannot be fully avoided, like for physical position of stuff when you need to pick it up: Box 43, row 14, room B, Warehouse East is an obvious one.

Who said tinkering with software should be boring?

:)

art, sheep and innovation

Kathy Sierra once again inspires with her post "We can't leave innovation up to our users".

I agree and I do not agree, depending on what the product is - practical or practical and inspirational.

The innovative concept, the executable mechanism, the art has to be delivered - but the translation into feelings, inspiration and unexpected use must remain with the user.

Perhaps it is the difference between art and solving a problem?

The difference between a novel and a manual?

The difference between mere transport and an experience?

It can be one or it can be both.

Is this where the border between good software and great software lies? One solves a mundane problem and the other also entices the user to create new ways to run his business or his life?

This hardware is art, and some unexpected users found a shelter... expect the best stuff to inspire and be practical:

[Henry Moore's Sheep Piece]

:)