Kenneth Lavrsen
- Name: Kenneth Lavrsen
- Email: kenneth@lavrsenPLEASENOSPAM.dk
- Job: Engineering Manager in Motorola, Copenhagen, Denmark. Electrical Engineer from The Technical University of Denmark 1987, Manages a hardware team developing professional radio communication equipment.
- Hobby1: Closet Software Engineer. Runs open source projects Motion (video surveillance) and Open2300 (weather station software for specific weather station family) and is part of the TWiki core team doing all the things no-one else wants to do.
- Hobby2: Radio amateur OZ1IDD
- Hobby3: Music and theater.
My Links
The text below is my personal throught for being here.
How Do I Turn Our Engineers Into Bonzai
Instead of a traditional personal roadmap topic I have created this debate topic to give some puch back to some of the requests of removing or hiding features in TWiki and other basic TWiki issues. By reading this you know where
KennethLavrsen comes from.
And it is meant to be a provocation so please accept the tone and the irony/sarcasm used in this topic as a debate statement meant to make people think and shape oppinions.
Scott Adams - with his Dilbert universe - did not grab "Mordac - the preventer of information services" out of nowhere. He is real. We meet them on the Support web and on IRC. They are the guys that ask something similar to "How do I turn my Engineer users into Bonzai?"
Hiding User Interface
This requirements come from at least two sources
- The grumpy old men that give complicated user interface as the reason for not touching TWiki
- The application designers that use TWiki for something that has very little to do with a Wiki
We should not let a few thick headed users that never gives anything a chance destroy a good user interface. These types of users are generally against anything new and just tries to give excuses for not learning something new.
Look at Microsoft Office and Windows XP. Microsoft started hiding the not so often used menu entries in both XP and Office.
The result?
- The very little experienced users never discover the features that are there. Or they search for them for hours.
- The more experienced users gets very annoyed and turn the feature off as fast as they can.
That feature is one of the dumbest things ever added to a computer program. I have seen both types of users. And both newbies and experienced users were happy when I helped them disabling that horror feature.
Now what is it that TWiki is doing so badly?
Look at the standard Pattern Skin. Look around it. What is so confusing about it that a newbie does not know how to navigate it? There isn't really that much.
We actually have a very clean interface!
Surely the "Edit vs Edit Raw" is strange. But that does not get better from hiding one of them. People learn quickly the advantages of both modes.
A button for attaching documents? Yeah let is hide it. Then we are sure no one ever finds out that you can attach files to a topic.
Printable. People that make web pages with a right and left menu always forget this feature. People - also the newbies - want to print the topics - and naturally without the menus. And we have the button for it. It is well labeled. Easy to understand. Easy to use.
Go to the bottom menu. Edit/WYSIWYG again. Attach and Printable. And what do we want to hide then?
Raw view? Great. The newbies will hit edit instead to see the code. IF they are allowed. Removing this feature means the end to users learning and copying code from ALLOWTOPICCHANGE protected topics. We need the raw view feature!
Backlinks web, all webs? Did anyone really say that these buttons made their life more difficult? Or do that say that they think that those features make it more difficult for others? You often hear users say: "This is OK for me but I think someone more dumb than me may have problems with it". Finally we have the history buttons and more topic actions. I do not believe for a minute that removing a couple of those links will change anything for newbies.
Hiding the link to the Form topic? Then it becomes less apparent that the forms are actually defined in normal topics. Why hide it? Does it harm? The form topic is a table that defined all the fields. Their name, type, size, and a tooltip which is actually a very nice help to what the field is used for - if you bother to write a proper tooltip. And you can add even more help in the form topics before or after the table. Hiding the form topic removes a nice help opportunity and denies the emerging Twiki application developers the inspiration to make similar applications. I have has several users add values to forms. For example my bug application has a field for the version number. And I often forget to add the new version when I release Motion. But soon one of the users add the new value and all is up2date again.
Surely if you want to use TWiki as a content management system or a Blog where few edit anything and almost everyone just reads and navigates then most of thise controls should be hidden. And maybe a "guest read only" mode that removes all features related to editing, raw view, history etc etc can help some that want to use TWiki this way. Then you can always create your own templates.
But this leads me to ask the very basic question.
Usability is not just usability
We often see the usability of TWiki analysed with the methods as you do with a public website that addresses potential buyers of products.
This is fundamentally wrong.
On a public commercial website you must assume your users are there rarely and often for the first time. The page needs to be quick to overview and quick to use.
But TWiki is is a
tool. It is a collaboration tool. Used well in an enterprise TWiki is a tool people spend hours in every weel. TWiki is a tool that grows on you and constantly gives you the impression that you can do more as you learn more.
We should not optimize the first hour of use at the expense of the following 10000 hours. It is like a car. There are many controls in a car. But they are all needed available to you and visible to you to be able to drive the car. It does not work hiding the controls for light, wind screen wiper, heating, hand brake etc inside the glove compartment.
Naturally we must address the usability of TWiki and we can do a lot to improve it. But it must be done in the context of TWiki as a tool which is quick and efficient for the frequent user, and easy to learn for the beginner.
Adding more complex access rights
TWiki today has a set of access rights which is a bit geeky to use but very simple to use once you are familiar with the syntax.
Sometimes we hear people wanting to have additional means to prevent people from editing pages on TWiki. This is the webmaster syndrome showing its face. This is people wanting to use TWiki as a content management system or as an easy to use web page builder. The power of TWiki lies in the fact it is a wiki. It is the wiki feature, the wiki idea, the wiki collaboration philosophy combined with the ability to build applications that makes TWiki such a powerful system.
We should not encourage administrators to build an application in TWiki and lock the whole thing up so people can do nothing else than use a few text fields in topics that can only be created in the application.
We may be able to get a couple of paying customers with these requirements, but we loose the whole idea of TWiki and in the long run all our customers. TWiki is a wiki on steroids The first application made by the administrator should just be a kick start to something much much bigger in any enterprise.
TWiki has the access rights features needed to keep content confidential to groups and individuals which is what is needed in an enterprise.
The one problem we need to address is to make the use of these access rights easier. Main problem is the "Edit Settings" in the "More Topic Actions". This should be changed from a bullet point syntax with no help into a section for setting acccess rights and an ability to add custom variables.
What does TWiki want to be?
There must now be close to 1000 programs in the content management/blogs/wiki/homepage building type of program families.
Some are very simple programs that can do nothing. Some are excellent at blogging. Some are excellent as news story tellers. Some are good document storage systems.
TWiki is a Wiki. It is a Structured Wiki. It is a dammed advanced structured Wiki. It is a wiki targeted for professional use enabling professional people to share knowledge and collaborate as a community. It is a tool that
enables people and
activate people instead of making them passive users or watchers. It is a tool that anyone can get started with with very little instruction and grow with. You can learn yourself by reading documentation. You can learn by example by "raw viewing" other users creations. You can learn from your peers. Seeing how TWiki grows on an organization is an incredible experience. And the worst enemy is the person that asks/suggest "how to I limit access to ..." or "how do I disable people from ..." or "you cannot let people just ...." or "I would like to hide...".
So we should not try and change TWiki into anything that does not
enable people. Naturally we have to have measures to avoid spam on those TWikis that are publicly available. But they are not the key target audience for TWiki. TWiki has to know what it wants to be and where it fits in the market and be the absolutely best in that position, and not try to be everything at once because you cannot both be a sports car, a fork lift, a heavy load truck and a city bus at the same time.
- TWiki is not a blog. You use TWiki as a blog, but there are blog programs that do a much better job.
- TWiki is not a content management system. You can use TWiki as a CMS. But there are CMS systems that do a much better job.
- TWiki is not a document storage system. You can use TWiki as a doc storage. But there are doc storage systems that do a much better job.
- TWiki is not an online photo album. You can use TWiki as a photo album. But there are photo album programs that do a much better job.
- TWiki is a Wiki. You can use TWiki as a simple wiki can can do nothing else than simple wiki stuff. But there are programs that do a much better job at being a simple wiki that anyone can write some funny nonsense in.
- Mediawiki is a Wiki that has been specialized as being dammed good at making an encyclopedia. And it is also pretty cool as a documentation collaboration for manuals etc. You can make some simple applications but there are other Wikis such as TWiki that does that much better.
- TWiki is a structured wiki. You can use TWiki to make an organization share knowledge and build quick and simple applications that will structure both the sharing and creation of the information. It enables anyone to continuously making the knowledge sharing better and better and make people organize their works flows, reporting etc. And we are no longer alone. There are a few other Wikis that are taking up the competition. And in some vital aspects getting better than TWiki.
But there is a problem to be resolved. TWiki is not as easy to use as it should be and could be.
Installation
Installing TWiki is a pain. With TWiki 4 we got configure.
- But why do have have to start with editing a text file in a text editor as the first step (bin/LocalLib.cfg)?
- Why isn't there installers and packages for the most common Linux distributions that setup the Apache config, the correct file access rights, a working configuration etc so TWiki works out of the box?
- Why do we have to protect configure with Apache access rights? Why can't it ask for password when you invoke it? Why does it wait till you save so you can see things and do things that you should not be able to?
- Why does configure jump on you with hundreds of settings that noone knows what half of them means and which ones need to be set? Why not an installation wizard that can guide me through?
- We have the EXPERT settings now but we still have no wizard.
- Why do I have to almost know TWiki in advance to register myself as an administrator? Why isn't there a create an administrator wizard that gets me through that hurdle from the beginning? (The temporary admin feature - also known as sudo login among developers - has not made things easier IMHO).
Use of TWiki
- The main problem of TWiki and any other Wiki is the markup language. People are used to Wysiwyg in all other programs.
- How do you edit in Wysiwyg mode when some of the features in a structured wiki is actually a sort of very simple programming. Just think about a formatted search - how advanced this can be. No way to Wysiwyg edit something you cannot see until the code has been rendered.
The problems to address with the TML are
- The syntax is geeky. There has been attempts to make Javascript based solutions to aid writing the TML and there is a big win to be made here when this work is finished.
- The TMCE editor has improved things a lot here.
- Tables in TML are hopeless to edit. You cannot insert a column easily. You cannot see the rows and columns at all when you edit a large table in TML mode. EDITTABLE helps but you have to be a geek to define it.
- Again the TMCE editor has helped a lot but we still miss being able to Wysiwyg table column widths.
- The context when you edit is lost in large topics. You constantly find yourself with two browser windows. One in view mode. One in edit mode. And you find yourself searching for text you see in the view screen to find the same place in the edit screen.
- An automated section numbering feature which also works in edit mode would be a great help. You can auto number sections using existing TWiki features today but when you edit all you see is some code and finding the right place is a pain. Sectional editing could also be a great help in large topics.
The Wysiwyg editor added in 4.2.0 was a huge leap towards a good Wysiwyg. The original version was very buggy. From 4.2.1 it is actually great now. Even I have started using it regularly. But there is still a lot that needs to be done to get it fool proof. You can still pull the side of a table with the mouse by accident and end up with an HTML table that only a geek can get back in TML mode. We still need work done on the Wysiwyg and it is many many hours of work. It is an obvious place where funding the developer will help a lot.
Documentation
- Documentation in TWiki is hard to navigate and overview. I would not say there is too much of it. But from Cairo to Dakar some topics were created that are just searches and if you really read what those searches come up with, then it is just nonsense words. Some of the docs simply needs to be organized better so you know where to go for information.
- Beginners information is not too bad. We have some good tutorials. But if people hide them because they hide the TWiki web then people are really left alone. And I bet many admins that say TWiki needs a simpler UI, also hide the documentation that could have helped them getting started.
TWiki is typically used in high tech environments. Many admins behave as if their users are all stupid. But in reality in most places the employees using TWiki are smarter than the admins. And yet in most organizations the admins first move is to limit access to all the computer resources in the company so the users have to fight or write stupid change request tickets to get even the simplest things done. There is little we TWiki developers can do about that. But at least we can choose not to listen to the arguments from stupid admins about their users.
And maybe we should add some "soft" documentation to TWiki for the admins to read and for the users to use as ammunition against the admin and management.
The title should be "How do I make money by using TWiki?" And should describe how to use TWiki and how to use the soft protection to
enable you staff to
create. Create value. An argument I use again and again when conservative people want to limit access is always:
Kenneths vision of TWiki
It has never been what what people do that is our problem. It is all the things they do not do. History tells us that we rarely have to tell staff that they did something they were not allowed to do. It is the common situation that we have manage, track, follow up, remind, prioritize etc to get things done. And there are always more to do than we have resources for.
My vision for TWiki is to continue developing the one tool that enables our staff to take initiative, be innovative, create information, improve information. improve workflows without having to beg for permission. And when it in a rare occasion happens that someone does something he should not have done, then TWiki makes it easy to restore things as they were before.
TWiki does this already. The future work is to maintain this unique feature and make TWiki
- Easier (user friendly, intuitive, while still fast)
- Faster (scalable)
- Better (new smart features)
- Protect existing content (can always upgrade TWiki)
Kenneth's view on TWIKI.NET
TWiki is the child of Peter Thoeny. He picked up the wiki idea early and had a vision about making a wiki a tool for the enterprise. And I share this vision and I trust that Peter is the best person to protect TWiki from evolving into something bad.
There are always many ideas and forces pulling in many directions.
As a corporate user of TWiki - the value of TWiki is maybe 1000 or 10000 dollars. That is the price I would pay for TWiki as a program (if it was not a GPL software) now that I know its value. But the content in our TWiki represents the work of hundreds of people for several years. The value of the content is probably in the magnitude of millions of dollars.
Technology changes all the time and as a corporation you need use all the new tools to keep up with your competitor. It is important as a TWiki user that you can constantly upgrade TWiki to new versions with the latest features. To be able to do that your old topics must still be readable and your TWiki applications must continue to work flawlessly. This means
- TWiki must always be able to read my topics.
- TWiki must always be able to understand my TWiki Applications
- All my installed plugins must continue to work. It is OK that I must upgrade the plugin along with TWiki. But such upgrade plugins must be present at the time I upgrade.
I firmly believe that Peter Thoeny is the right man to ensure the above requirement is never compromised.
TWiki is a tool that targets the enterprise. It is not a toy. It is not an academic playground for idealist programmers. It is a kick-ass tool for businesses. And being an enterprise tool it is also a potential vehicle for generating income for those that develop the tool and support it. Generating income means that some can work full time and not only an hour here and there.
TWiki has from the early days had a long string of individual consultants offering their services. But seen from a corporate IT executive TWiki has not looked like a fully commercially supported tool.
- What happens if we get a major problem?
- Who will maintain our TWiki if the administrator geek leaves his job?
- Will TWiki exist in 10 years?
Those are questions any executive will ask before deciding to install and use TWiki in a large scale.
Some list of individual consultants does not give the warm comfortable feeling. The presence of a commercial entity created for the single purpose to support, develop and maintain TWiki as a product does give TWiki its much needed business legitimacy and security.
I believe that a strong TWIKI.NET will be able to feed resources into the project and speed up the development of TWiki.
But a new business like TWIKI.NET will need to build up a customer base first. It will take years before TWIKI.NET becomes profitable. I am convinced that if the community supports TWIKI.NET - we will see a strong flow of resources. But it will take 2-3 years!!
What about the other businesses?
TWIKI.NET is not alone on the commercial scene. They are actually a newcomer.
But looking at the businesses the existing businesses are mainly consultants that help customer installing TWiki, building TWiki Applications, and integrating TWiki with already existing corporate tools.
This is not at all the business model of TWIKI.NET. TWIKI.NET offers a certified distribution on a subscription bases. Their support net consists of a net of independent consultants. When business gets good for TWIKI.NET it gets good for consultants. More customers of TWiki means more business. Both indirect through TWIKI.NET and direct where customers deal directly with the independent consultants.
There is at the moment no other commercial distribution of TWiki. TWIKI.NET goes in where there is a huge gap in the commercial presence.
It will be good for TWiki as a product to have a strong commercial entity behind it.
What should the community expect in return from TWIKI.NET
There are a number of thing I expect
- As a community member and contributor I should never be in the situation that the open source version of TWiki is a crippled version of TWiki. I should not - with all the hours I spend as a contributor - find that I will have to pay for features for TWiki. I contribute and I get other contributions in return. That is the whole idea behind the business model. TWIKI.NET should add value to the paying customers by adding services. Not by creating proprietary features. Part of services can be access to automatic updates.
- As a community member I should never be prevented to add a feature with the reason that this should only be available to paying customer. If the community wants to implement a cool installer - we should be able to do so.
- I expect TWIKI.NET to take active part in the creation of releases. This means not only writing code but also certifying the software. If TWIKI.NET continues to be one version behind in their commercial product then
- it will solely be the volunteer community member that does the hard work of getting stability
- the value of using certified TWiki instead of open TWiki will be lower. I will assume customers want the latest features on a stable platform.
- I expect TWIKI.NET to be the prime sponsor for the community resources (servers, hosting). If TWIKI.NET reaches a point of making good revenue I also expect TWIKI.NET to fund Summits. I expect the level of sponsorship to follow the revenue stream which means I expect very little the first years. I prefer to always be able to count on that also next year someone pays the hosting fee for TWiki.org. I see no reason why a foundation should have to beg for money. I'd rather focus on development than begging.
- I expect TWIKI.NET and the BDFL Peter Thoeny to respect the community. We are here on a volunteer basis. We are here because we share a vision and as a community we expect some degree of autonomy from the commercial cousin.
- I expect the BDFL Peter Thoeny to protect the TWiki mission and the users's interest. They have a weak voice in a developer dominated community. I believe Peter is the right person to protect the users and their investment in content in their TWikis. And this is why I support Peter as BDFL. But the BDFL role should not be abused for personal or commercial agendas against the community. The community can at any time fork. It would be a bad thing but it is the possibility of a fork that keeps the balance between the community and Peter/TWIKI.NET. It is knowing that you cannot take the community for granted but have to show respect that ensures the BDFL role is not abused.
Is Peter always right?
No. At least once per year he does something really wrong. I would even say stupid.
But then think about this. Peter is trying to be a leader. You can read 100s of thick books about management and leadership and we have come to expect a leader to be flawless and perfect. Problem is that no person can be perfect. No person can work every day without making mistakes. Peter has made mistakes before. He will again.
But then go here:
Bugs:WebChanges. As I write this developers have made 5774 mistakes since we created bugs web. And in some cases it has been difficult to convince the developer that his mistake was indeed a mistake. Some of the bugs can even be characterized as stupid by the developer himself once he has fixed it. We have come to expect a software developer to make mistakes. We are so used to it that we do not even feel bad when someone raises a bug report against our code. But as a leader you are expected to make no mistakes and when you make one you are expected to commit hara-kiri in front of the mob.
We have to accept that we all screw up now and then. We all have good days and bad days. Naturally we should react when Peter makes a mistake just like I write a bug report and push for it to be fixed when a developer has broken something. Peter on the other hand also needs to fix his bugs. He makes 1-2 leader bugs per year so the rate is actually quite low compared to most of us.
Topics I have contributed to:
(sorted in decending date order so that I can see when there's activity)
