Cataloguing the Different Ways the Mind Associates Itself with the Outliner Presented Screen

Posted by Foolness
Sep 12, 2012 at 06:16 AM

Daly de Gagne wrote:
>Foolness, you wrote the following:
> >“In fact as far as web services go, Google
>Calendar is much better at recreating and unconsciously motivating it’s
>users to experience the Kanban style of thinking without them needing to know or
>realize it because it mimics a work style much closer to the paradigm rather than going
>away from it.”
> >I may be obtuse, but I do not understand how “Google Calendar is much
>better” etc.in terms of Kanban than Flow.IO or Trello. I’d appreciate it if you could
>explain. Please let me know what I’m missing.
> >Thanks.
> >Daly

“Much better” wouldn’t be the term I would use. Truer to the model would be more accurate which is why I stated: much better at recreating and unconsciously motivating…

I don’t really find the conversation of much better here that useful because it leads to arguments that one mindset is superior to another mindset for everyone which is the direct opposite of what this topic is supposed to be about. Even the last mindset, the rower, has a huge flaw to it when viewed by someone who isn’t as attuned to the rower design of a particular file. Not even if they can attune to most rower attuned screens.

I think it would be much clearer to see the comparison from a teaching tool perspective than a pre-existing tool to be used because in the end Google Calendar software is still a calendar. It just happens to have a (in my view) “truer to the model” at training a user’s habits to experiencing the intangible effects of a Kanban.

But this goes to the heart of why the Kanban is very tricky.

At the heart of many of it’s effectiveness is not “what” the model is but at “how” the model affects the people.

Since it’s primarily used as a collaboration model, even the how is not as important as what the work group is.

If this reply is too long, please use your browser find in page and type in “(mediummediummedium)” for medium length and “(shortshortshort)” for a direct but sorely lacking in details reply. If you want to go to the extreme, (extremeextremeextreme) leads to the one paragraph section but it’s not the last part of the post which is why you need this.

That is to say: in any collaborative setting, it is rare that the superiority of the model trumps the preferential habit of the group. If a group wants or have to abide by a particular work flow assigned by the leader/manager or director…they have to; but when talking about models, the model structure should inherently move ahead of the people to separate effective groups utilizing a software to a stand alone effective model.

At the same time most of this is moot as my post deals with the particular behaviour of one individual and even a group has to work as individuals being slaves toward their eyes and their mindset per each viewing of not just a Kanban but any outliner output in general.

I only bring this up because Trello/Flow.IO is primarily a collaborative tool (though individuals can use it) and also it helps me follow up on my metaphor below:

Unlike a straight software or a technical model that relies on…say branches…like most outliners do:

A kanban is very much like that open window in a restaurant that separates the cooks from the servers.

If you think about it from an aesthetic or a mechanical view of the concept, the window is really no different than an order station or a telephone call. Maybe even inferior because of the lack of range. The insistence on expected cues like the server needing to write clear orders and the cook needing to stop what they are doing unlike the order station. In fact, from an aesthetic view, the window is even less efficient than the designs found in a drive through window that serves up cues on what the special is for the buyers in the form of posters, clarifying questions, directions on where to receive the order.

Yet from a simulation of the model, the open window scales better than the other models, for that particular tasking of cooking. At least, most of the time.

Why is that? That’s because the design has a dis-associative effect on the two groups that the other designs don’t.

If you hang a piece of order for the cooks, the effect is minimal.

But as you hang several orders and as problems arise, the behavioral impact is much more clearer. The cook inside does not dilly dally. He doesn’t wait to make chit chat with the server or try to waste time interpreting and carrying the load and quickly heads toward the conversation of why the writing isn’t clear. The server too doesn’t wait to make friends with the cook regardless of whether they are friends or not.

Comparatively, the Kanban model (for groups) is very similar to this effect only it’s beyond a two group dynamic.

That’s why despite looking the same, especially for random groups, there’s a vast difference between sticky notes and a kanban. One is designed as a plate for notifications, reminders, anything notes do. If refrigerator magnets can scan and transfer data to the next recipient, it would be a more powerful sticky notes but not a powerful kanban.

On the other hand, most notes on a kanban (from the Google images I’ve seen) are very small. Not that notes are often lengthy but we’re talking about one or two words most of the time. Yet the column titles are often very large and very specific. Most importantly they are very close together. If you are standing in front of one column and you just extend your arm, you could probably take up one or two columns without doing much movement.

As a singular concept it’s not that very different from how Trello/Flow.io designs the space but if you go beyond the board and also look at most of the characters in those sticky notes…they are very potato chippy.

Almost all if not all entries on the doing list can be moved towards the done list or the to do list column. Most kanban with a month model don’t have fat columns where you can put many sticky notes on it. In fact, the more asian it is, the more the kanban seems to be squished together and I’m not just talking due to the character letter changes.

That’s the dis-associative factor right there. On a group it’s not very noticeable but it works because most groups have a constantly rolling and busy workflow but as a personal kanban, the effect is very noticeable. Almost as noticeable as say putting an empty personal suggestion box and having that suggestion box be any different or more efficient than any random box. Sometimes it could even be counter-intuitive. A plain box with a slap dashed post saying Items that you just randomly wrote down can have a much faster filling and item removal effect than an official personal suggestion box.

...except with most of the software Kanban designs.

Most of the software Kanban designs work on two major principles. The entry can be dragged around or maybe moved towards one column or the other upon a particular context of work and they work towards fitting those columns into place.

That means that the more work and entry you put into those services, the more you have to think and invest upon the entries.

In order for you to start dis-associating with those entries, you have to manually move those column boxes into a different dashboard. Maybe archive them. Maybe set them on a different list. Maybe make it so that you’ll be notified instead.

These doesn’t mean a group of collaborators can’t make it work. But they are artificially making it work. That is to say, the model isn’t making them work or think or input things in a certain pattern. If they don’t know kanban, they’re not going to feel the functionality of a kanban. If they are not feeling it, then whatever that is that they are feeling IS different. And whatever that is that they are currently experiencing and thinking as kanban, will fall apart as the group falls apart or as the entries change in scope, scale and objectives. A good group won’t succumb to that but a good group won’t succumb to most things. It would be like a band who’s great at jazz giving up on being a jazz band because they don’t have saxophones. They’ll adapt.

It’s not they that models are studied for. Especially behaviour related. It’s all about the unconscious or the subconscious long term effect and I’m using these terms loosely.

Even if you are conscious, if you’re tired/if you’re putting in the wrong words/if you’re of a different mindset…whatever the model is, falls back to being the model. An economic model that works differently, that is being made to work against the model, would eventually fall even if you have people making it work. Even if those people are top notch, the model would be working on a sub-efficient level for it’s duration of existence.

The opposite is not true which is where I’m going to get at with Google Calendar.

Much in the same way as a person can get rich without knowing (or at least optimally knowing) economics so long as they have the attuned model to the current trend of money making…say timing a business during the Industrial Age-like boom of a particular country, they can potentially be made more efficient than someone who knows what’s really happening economically.

Especially if the data is not set in stone. Like the thing happening with which economists gets to be the talking head in most mainstream television. The battle is neither cash nor skill nor knowledge but charisma, information deliverance and notoriety.

With Google Calendar, it’s kinda like that only I’m not talking about cycles or timing but on how the eyes and the mind are interpreting and being subtly modified by the output especially if the output is something that the eyes are constantly seeing.

(mediummediummedium)

If you use GCal as a calendar instead of a kanban, you won’t notice it but the disassociating effect is still there if only because it’s a calendar. Whatever you put in there will move on unless you constantly duplicate the entries or find a way to auto-make entries. This factor isn’t important except to keep in mind that this alone would make the GCal differ from Trello/Flow.io just in terms of how a user might input and expect things in it to “move on”.

Now if you use GCal with the vague idea of a kanban and compare it to Trello/Flow.io…here’s what I think would happen.

Trello/Flow.io would be better at capturing lists. Capturing posts with multimedia. Notifications. Finally storing the entries. Basically the pace would be very relaxed “within the model”. An urgent task would always be an urgent task but a neutral item would slowly drift away inside the service until the fingers/keyboard shortcut moves it.

GCal would be poorer in terms of all those general functionality because it’s a different service with a different functionality. Even in things task related that rely on deadlines, it’s simply not the place you want to say…put something that could be put in Google Docs first or e-mailed as an attachment first before being supplemented by the calendar. However GCal based on it’s model would always have something that makes the items inside of it have a natural more urgent priority than either Trello/Flow.io and because of that, the pace is much higher. Nothing urgent when urgency isn’t required but on a general level, it’s going to be of a higher pace even if the person was a slow worker. Their mind simply would be interpreting the entries at a much urgent level even if they were not doing anything with the entries inside.

Most of the above though is only necessary to know in order to get back to the heart of the kanban’s intangibles such as disassociation, micro entries that can apply to each column and prolonged effect on the human behavior.

The below is really where this all wraps up. Especially this being a software outliner thread, the priority should be to get at the heart of not just the difference between two software but at how outlines are used to segregate different bits of data. (Assuming the outliner can support other bits of data aside from text.)

(shortshortshort)

At the essence of it all, the core difference as to why Google calendar can train a person to a much truer mode of kanban over Flow.IO and Trello is because Google calendar, as with most calendars, are designed to have smaller bits of data inserted into it even if the difference is a word vs. a phrase.

A calendar forces the user to put the pepperoni on top of a pizza or to roll the dough on the crust. In cases where there is miscommunication, the Google Calendar is training the person inputting the task to put the entry to contact the person where as Flow.io/Trello is telling the inputting user to call/e-mail/show the opposite collaborator what is it that they need to show them. Albeit using the particular service that is being mentioned instead of say an instant messenger.

Especially for personal outlining use, the difference between the two services is day and night for someone who’s pacing.

An individual loses most of the collaborative features of a kanban. (The model not either Flow/Trello’s design of the model.)

Assuming despite this they would still try to utilize a kanban or a different pacer dominant outliner, they are particularly vulnerable to the storage mindset by Trello and Flow.io. Even if they have a good personal time management skills, what inherent feature inside these services would cut off their data for them? Especially the non-task related ones.

It’s easy to morph a task from doing to done but the general data? Dragging dress to a list called sewing isn’t going to auto-morph the entry into materials and machine. No, you’d have to do all that by yourself. While you’re doing all that, you’re not able to function at a foot soldier mindset that consistently. Eventually the data is going to be tuned out by the user and all they would care is the dragging.

For a general outliner model example of such a phenomenon, imagine every time you create a sub-branch, the software asks you what shape or name of the branch you will create. Eventually it will wear down the pacer’s mind. They’d end up functioning much closer to a pulling mindset and silence the form of the tasks inside and prioritize the list name on top of the objects below it.

Google calendar or any calendar software won’t morph the task either. In fact, the service won’t even allow for quick attachments but you know what that does to the users’ brain?

It disassociates the entries.

For example take the Google default example of breakfast at Tiffany’s. The more breakfast at Tiffany’s you do the more you’re going to be sick of typing in Breakfast at Tiffany’s. You’re going to start typing in things like “Where to go today for breakfast” or “What to eat today”. With Trello/Flow.IO you’re going to start trying to put entries relating to breakfast at Tiffany’s and then eventually you’re going to stop and you’re going to set that list aside. Maybe pulling it open when you need to access that information but the average person is not going to be constantly pacing through that list unless there’s a notification on it.

(extremeextremeextreme)

In essence, Google Calendar, like inherent mindset of a pacer/my interpretation of the kanban model, is mixing coffee with a stick. Trello/Flow.io are knives. You can mix coffee using a knife but when people’s mind are groggy and there are no spoons around, they are more apt to pick up a stick instead of a knife in their head first.

This doesn’t mean Google Calendar is the pre-existing superior kanban tool.

In fact even the interface, especially for personal use, there are Trello/Flow.io variants that can simulate the pacing mindset better than Google Calendar. Teux Deux is one example I mentioned before but really there is no one true kanban example that is superior over another out there especially as kanban is used more as a collaborative concept than a personal web service.

It just so happens that the concept of a kanban matches very well with a pacer’s mind especially if we’re talking about software outlining. At least on the bare surface as I said I’m not an expert.

Epecially for personal outlines, the kanban columns are extremely good at turning even unrelated concepts into recipe style lists and then cutting off the fat.

It’s no agile method when used as an outlining mindset but just on the general scale, it’s still a lean method of outlining.

In fact I’ll try outlining this reply using both methods. Once again I’m not a kanban user and I’m not sure I have a pacer’s mind and the actual principle in my opinion should be done through a prolonged period of time but hopefully it would be of supplemental help to my explanation. I’ll be using Trello first as it’s easier to share that then I’ll be using Google Calendar. Note that this is not a a general outline but an outline trying to channel a Pacer’s mindset as I’ve described it and is outlined with the objective of looking at it daily or even like a sections for a bible study if the organization reads too radical from the traditional elements you find in a general outline. For this reason, it’s not going to look anything like things you normally see on GCal and Trello. In particular importance is to not see GCal’s dates as appointments or specific numbers.

Shared Trello Board url: (This is tested with Private Tab with no login but I’m not sure if Trello has a deadline/limit for shared links.)

https://trello.com/b/lh4OHXU7

Google Calendar Screenshot (This is in Agenda view but it was made in Week View; also note that because GCal is a straight calendar, some #6 mindset was mixed with #5 but only with regards towards how the entries were outlined not as texts are to be read after they have been written.)

http://img6.imagebanana.com/img/9kr0vp2d/Selection_001.png