demo snippet

Not having much to do on a Sunday - except doing four times 12 minutes intervals uphill  (Pre du Lac to Caussols for those in local know) in feeble preparation for the upcoming Mt Ventoux ride - so thus I tried my hand on recording a little demo.

Nothing fancy, just a off the top of my head no manuscript build of a simple procurement process with a couple of report and accounting templates - about 20 minutes including a run, looking at some reports and some fixing of errors...

Will now proceed to hone my demo and video compressing skills... ;)

The demo link is on thingamy.com.

[Update: Forgot to capture the full browser, but it is a browsere, web using server based stuff this etc.]

Comments

[Alex]

Sig,

I've been following your blog on and off for 2 years now... I have always been very intrigued by 'thingamy' ever since an early discussion with you about Tagging.

I kind of thought it did cool things, but your deliberate vagueness let my mind get carried away... I wondered whether it did something similar to what I've been talking about to my colleagues.

Well I can see now that it does. Well done cool stuff.

BTW are you going to go up Mt Ventoux next year too (or maybe the Galibier or Alpe Deuz)? If so I'll be in, unfortunately I can't get from NZ to France this year... also a year's training will come in real handy!

[sig]

Alex, thanks, thus the first stab on a demo video was worth the effort!

Agree, no reason not to make the climb or other cycling arrangement an annual thing... I'll suggest it to Thomas and Hamish and who else turns up for our first one :)

[John Dodds]

No car chases but still a great little movie! It brings real clarity to those of us who are non-experts. Very impressive.

p.s. As you know, I can never avoid offering opinions, so from a marketing/usability perspective I would say that the naming of the categories is key. For example, the word stack had no meaning for me (though perhaps it is a well known term for potential users) and thus it is something I would have to learn if I were to be a user.

I think it worth considering, as you move forward, whether usage can be made even more intuitive by choosing category names and indeed icons that facilitate immediate understanding.

[sig]

Thanks John!

And you're absolutely right - naming is important - a never ending discussion so far, but we decided to stay semi-geek until more or less all is in place (so we should start tinkering with that very soon).

But it's no easy task! "X-or branch" or "choice", "Stack" or "..?" - most of the names originates from the code, and then I get used to them... perhaps we'll have a button on top saying "Geek or human-compatible" :D

But we'll get to it in the same sweep as when we sort out the interfaces (reports are still in pure code mode) and the manual (arghh do I dislike messing with that) - most important it still is.

But I'm quite pleased when I'm allowed to use the term "cookie-cutter" instead of "class" ;)

[Sheamus]

Good demo Sig. As a non-tech your demo (visual and verbal elements) enabled me to find a starting point. My (limited and possibly faulty) understanding suggests thingamy: [1] enables the user to name a process [2] to create the workflow (including the buckets for data) associated with that process [3] to include the necessary detail (including the buckets) for the workflow. [4] and it appears (I may be incorrect on this) that the underlying technology logic/coding et al remains hidden to the user. Thus, they only have to focus on the process, workflow, reports and so on.

You mentioned "color coding" for different parts of the workflow (e.g., elements involving people have one color)... Very cool!

I loved the linking capability and the assigned unique linking symbol.

Could thingamy be used to create a complete financial management system?

[sig]

Thanks Sheamus! And yep, you got it right...

And when you have built those workflows where the objects (each representing a real world object, physical or virtual) are touched by humas when the flow is running to add value through manipulating adding info, combining or whatnot - then everything is captured - every change, every item added, who did it, when, what was changed.

Thus you have the basis for the accounts and things financial - if the system knows that you have moved a part into the warehouse it has the real data in real time for the inventory and balance sheet. When you move it out during a flow and screw it onto a new bike it knows that it has been "used" and thus is another snippet for "production costs" and the P&L and so forth...

Thus all things financial is about report templates that maps certain objects and happenings and places to an "account" - thus no need for separate input of anything, no real need for the accounting department (the input of invoices etc at least).

Accounting is after all just a "tracking" of real world happenings, here the real world happenings are captured directly.

So accounting/finacials are dependent on what scope the system is used for - only procurement as in the demo then only finacials from that part, if it covers all processes then it can do it all, and more :)

[John Dodds]

Don't get me started on manuals! As I commented on Kathy's excellent recent post, it is something that should be tested as much as the product.

In the case of Thingamy, both the manual and the naming can reinforce the simplification of the product by themselves being simple and unambiguous. The more all this hangs together, the more it markets itself and generates recommendations.

Thoughts from second viewing of film -- Cookie cutter is good, but does everyone understand it and doesn't container actually mean location or place?

[sig]

John, one thing I'm sure of now is that putting up the video snippet was well worth it! Agile business indeed - let the market sniff and tell what's needed - have to love the new world of open communication!

And you're all so right (including Tara over at Gapingvoid comments) - even if the users of the "builder" interface mostly would have a serious geek streak - making it human-compatible and friendly and easy should enhance the basic claim that the system is simple (compared to the big ones at least, name not mentioned) to use.

And the best of that, comparatively (to concept and coding) easy to fix, time and money wise at least :)

*rolling up sleeves, putting on thinking cap*

[felix]

Hi,

Thanks for the demo. Something to look at is always nice. I would like to drop my 2 comments and 2 questions, hoping that they will neither be lost nor offend.

Jumpiness: Whereas I think that stack and integer is acceptable as vocabulary because learnable, the fact that the interface jumps to the top of the page and not to where you were before will be a constant nuisance for the Guy Who Has To Use It. In a more complicated workflow it will be a lot more difficult to find your way back to the place where you clicked on "add fillout".

Icons: You have little imagery around (which I like) but for the workflows you have "instructions" which are coloured geometric shapes ... these speak less to me than "stack". Why not words? These things are called "Object-maker" and "Link-instruction" later, so why not have a "Link" and "Create object" immediately? You might even save some space, your icons at the moment are quite space hungry. Words are composite characters (which are sort of icons) which have collected meaning. Newly introduced icons do not collect meaning that quickly.

Question 1: Is there any undo feature? Since you seem to be able to modify the structure of your live database later, it might be scary to do something without any possibility to go back, especially in build mode.

Question 2: The data aggregation is at least partly human-driven, thus errors are bound to happen. What happens to reports, especially reports on former periods ... do they change with the data? As an example: If a report went out to the regulator, you will want to keep the report as is, but have the data corrected nevertheless. If the reports are not versioned, you would have to keep that in paper somewhere, outside the system ... or if worse comes to worse, you might keep it in a spreadsheet!

After all that: I like it.

Cheers,

Felix

[sig]

Hi Felix,

your comments are much appreciated! Let me try to answer...

Jumpiness: Agree completely, annoying when I now see it. Should not be a problem, is on the list. Just forgottent that one as I usually shorten the flows by using branches and even separate flows to be reused (you can map back and forth) as "operators". Is on the list to be fixed!

Icons: Plan (read test-and-see-how-it-works) is to have nice pop-ups / mouse-overs with more text than just name, examples comes to mind as they're easier read and give more meaning often than dry explanations. But we might do text directly too, will try many different tacks there.

Question 1: As you say, anything can be changed at any time while live, just by drag and drop. Suspect what you're alluding to would be more like "revert" to former stage? That should be easy, today I just take a snapshot of the system at whatever stage I'm at, then revert to wherever needed. In addition we do have revert during runs in case somebody chooses the wrong path - not unlimited though, just enough so it's oops proof, not real idiot proof :) And you can historically browse the system as well as data (but you cannot change anything when in historical mode of course!) if you only want to check out what it used to look like before the changes.

Question 2: You got the essence there - reports are created on the fly according to the templates, then dumped - only raw data is kept. For what you mention here you can at all times use historical browser to choose any time past down to the minute to see the exact report created that day and time.
So if you produce a report at 12:01 on July 5th, then make some changes to anything - system or objects (data) - two minutes later, then need proof or copy of that exact report prior to the changes: Set date and time above in historical browser, click apply (it pops then to home) and click on the report, and voila you have the exact same, exact. You could even delete the report template on July 6th, still in historical mode it'll pop up again as if it never was deleted.
Historical browsing gives you the exact situation for everything, even your todos are back, for that moment in time you chose.

There (will be) change logs as well - for the system as well for objects. Thus in principle a CPA could OK your annual accounts a year ahead, then pop by and check the logs to see if any have tinkered with the system.
And important for regulations - SOX, Basel II, Health reqirement - is that no object can ever be deleted (if something is "deleted" in the system, it simply has become hidden, not real deleted) and every event is recorded with time, who and what - thus complete adherence to the spirit at least to any of the above is assured. Given the system is actually covering the aspects in question opf course, i will not take responsibility for what other systems does :D

Oy, that was a long one, love to answer such questions...

[Felix]

Thanks for the answers ... I have another one. What if you need a report for - say - August. You browse back to 31/08/2006 to run it, since colleage A started - as planned - some major initiative that should not appear. The you realize that colleage B has not entered all data he should have before 31/08/2006. Can you still make that report with inclusion of what B forgot to enter, but without the data from A?

[sig]

Felix, a practical and philosophical issue:

For A - anything that happened post the point of time in historical mode is not included, anything before is included.

For B - in essence it will not be included if added after the point of time. Now this is a matter of philosophy and regulation - there is no way to botch or cheat the data in the system - but you are allowed to tinker with reports of course, setting rules and constraints as you please (and that in itself is also recorded so the integrity is kept).

So, it is a question about what kind of "data", let's look at the two main report types - normal reports (using object properties) and accounts which uses metadata like unit-cost, initial and current amount as well as timestamps:

"Normal" data (object properties like text): Here you have a few choices, create a report (or report group) template that includes what you want and not what you do not want for a point of time - and call it "Felix' special report". Each report template will look into all objects of the chosen class, filtered by all or user chosen matching tags chosen, displaying also linked objects by set filter or not and display chosen properties in the way you want (rows, columns, cells today). But most important you can add as many constraints you want using all properties and metadata including time-stamp following most any logical rule to match another set of objects including user input. Then you can put together report-group templates using any number of report-templates in row or column form.
I think that you will be hard pressed not to be able to create what you want whatever the situation is.
A bit of work, maybe even involving the sysadm, but it secures the integrity of the system - and thus SOX, Basel II, etc etc.

"Accounting" data. The system is built so that it captures pertinent data from the actual flow - move a part into the warehouse (a workorder), and if set to that (as per German GAAP say,) it has the part as inventory as of the moment the chap who did it presses complete.
If you rely on the old world of adding data - like invoices - well then that would be a ad-hoc admin process and quite like buying a car to replace the horse and carriage but hitching the carriage to the car trying to drive it from the carriage :)
Then you have the good-old reconciliation, a phenomena unknown to thingamy if used for what it is designed. Bonus using it right is that you can see a true balance on January 15, 15:42, then see one for January 15, 18:55!