Tags:
compatibility1Add my vote for this tag twiki_community1Add my vote for this tag usability1Add my vote for this tag create new tag
, view all tags

Developers Vs Users Discussion

Refactored from ProcessToDocUndocumentedStuff

KennethLavrsen expressed oppinions on how corporate users would like TWiki to maintain topic compatibility backwards to protect the value invested in creating the information that the topics contain.

SvenDowideit followed up with the statement below.


there seem to be 2 competing goals here
  1. the Corporates that have a desire for TWiki to remain the same
  2. the unpaid deleopers that want to work on something interesting

now, why does group 1 seem to expect to tell group 2 what to do?

-- SvenDowideit - 15 Jan 2006

You could choose to receive the inputs from (2) in a much more positive way.

I know that what drives me to develop Motion are mainly two things.

  1. Having fun. Learn something interesting all the time and participate in a community making friends all over the world.
  2. See that a lot of people find the work useful. And learn from them what could make the project even better.

I am sure these are the same objectives that drives you and all other TWiki developers. And I am also sure 1. is the highest priority.

Sometimes developers make some pretty important choices. The right choice benefits the vast majority of users. The wrong choice can mean the end of the project. A project like TWiki is used by so many different users. There are indeed the large corporations. And there are open source projects. There are small websites where one person shares information for his family. TWiki is one of many wikis. Each wiki tries to target some specific profiles and TWiki has always targeted the professionel use. Often used behind a firewall and typically within an engineering type application. But it can also be really useful on the Internet which my Motion project is a great example of.

When I compare the two TWiki installations that I have responsibility for their use and requirements are in a surprising way more different than I thought they would be. So I share my experiences so that you all get one more piece of the jigsaw that makes up the community of users and admins (customers is a funny word to use for people that get something for free but that is what they are anyway). I do not tell you what to do. I cannot. You can just ignore it all. We get more than what we pay for no matter what. I encourage you to take my input together with all the other inputs you get from other users and from fellow developers and base those important decisions based on the whole picture.

So are developers, admins and users in a conflict situation here? Or do they have common interests?

You will find some small pockets of conflicting interests but overall I think we all have much more in common.

There are 100000 projects on Sourceforge. When you chose to work on TWiki instead of the 100000 others - that is already a pretty good sign that you are in agreement with the whole idea behind TWiki, where it comes from, and its current userbase.

Most developers are TWiki customers. You probably have one TWiki. Actually you probably maintain a couple of them. Some of you run a corporate TWiki. Some run a small personal one. It is difficult to know how it is to be a corporate TWiki if you do not use or admin one yourself. It is also pretty difficult to imagine how it is to have a TWiki on the wild internet when you live a protected life behind a firewall protected from attackers and with no anonymous users. My point is that we can learn from each other by sharing the experiences we have.

I am not really a TWiki developer. My perl skills are too rudimentary. But I contribute by testing many hours every day. And my keeping a SVN beta up to date at the office where my power users can play and report bugs to me. Sometimes it is an advantage to have people that are not sitting looking at the details of the code but see the product from a distance, validating requirements and feature implementations. See me and my type as a tool and not as someone telling you what to do.

At the end of the day I think we all share the same goal. To create something great. And when we work on Dakar we both want new users as well as having the existing userbase upgrading to Dakar.

I run two different TWikis. Let me share some experiences. I will start with the ones I administrate.

Motion TWiki - Public TWiki on the Internet - Open Source Project Site

  • Users are mostly geek types that are Linux users, can compile their own software, can start a daemon from command prompt.
  • Users never complain about " * " and "---++". They learn it fast and love the freedom a TWiki topic gives in for example a bug report topic compared to a strict format bug database.
  • Users that don't like the Motion TWiki just stay away. Or they post on the Motion mailing list.
  • Site is often attacked.
  • Site is often spammed. This includes bogus users that register, spams and leaves.
  • Number of topics is limited. Maybe a few thousand. 70% of the topics are junk two years from now.
  • Admin has all the time in the world. It is his hobby.
  • If some topics are lost the value lost is nill.
  • If the site is down for 2 days - so what? Too bad. Come back later.
  • Access right to pages is generally not used. Only administration pages are locked. And a few personal pages that the admin has.
  • Upgrading to Dakar will be easy. If I have compatibility issues I can fix them or I can just abbandon the topics that have a problem.
  • The TWiki runs on a 512 kbit ADSL line. The speed of TWiki is limited more by this fact when accessed by many simultaneous users than by TWiki itself.
  • Traffic is global and evenly distributed over the 24 hours per day and all 7 days per week.
  • The Motion TWiki is also used for the projects "Open2300" and "PWC documentation". Number of webs is still low. Only 6 in addition to the Main, TWiki and Sandbox. Subwebs will probably never ne used.
  • Guest access is allowed - also for editing. Users authenticate using standard Apache .htpasswd authentication. The new registration scheme where people receive an activation code is very welcome and will prevent some spammers from registrating.
  • The visible email accounts on people home topic is undesired. People today use bogus email addresses to avoid spam. With new registration this is not possible. Secret email address would be a nice to have feature.
  • Upgrading TWiki with bugfix releases is a pain. When I upgrade I take a full copy of the old installation, upgrade the new and manually fix the things that got overwritten and should not have been. Live site is probably affected an hour or two but I don't care to much.
  • Data are backed up to another Linux machine weekly.

Motorola Copenhagen Engineering. Non-public - Intranet site

  • Users have to use the TWiki to do certain parts of their job. Users range from enthusiastic to "I hate TWiki".
  • Geeks generally love it or learn to love it
  • Managers generally are more reserved. Especially because of lack of WYSIWYG. "Can you put the information on your TWiki page in a power point presentation?" is a common demand.
  • The TWiki is used for a Quality Management System. And it is a success. We have never seen our QMS being updated more often than it is now.
  • The TWiki is used for knowledge sharing for projects. Those that have invested a few hours in playing with the many TWiki features are getting very effective tools with very low investment.
  • The number of topics is exploding. The site has a success that is at least 10 times higher than I imagined when I installed the server.
  • The value measured in staff hours contained in the topics is probably already millions of dollars. This is why backwards compatibility is essential.
  • If upgrading TWiki means loosing the information in a significant amount of topics - we will never be able to upgrade.
  • The TWikiMission says "Protect corporate investment (topic contents) from data corruption and incompatible changes - don't require the use of upgrade scripts (e.g. category to forms upgrade happened automatically)". This statement was THE decision factory for choosing TWiki among other Wikis in the first place. However I disagree that upgrade scripts should not be required. There could be examples where this would be acceptable instead of dragging old compatibility code that hurts the performance of the TWiki.
  • The admin of TWiki (KennethLavrsen) has max one hour per week to do it. Often administration is a weekend overtime activity if the site has to be taken down.
  • Access right are used a lot. Especially edit access rights are added to pages. Administrator often has to encourage users to use edit access rights less to ensure that TWiki is used as a wiki and not just as CMS.
  • Upgrading will be a problem. I still have some compatibility issues. For example CompareRevisionsAddOn is still not Dakar compatible and we use that on all our QMS topics. But the goal is to upgrade because there are many new features I would like people to have and WYSIWYG is going to be essential to get management to use TWiki.
  • TWiki runs on the corporate Intranet. The number of accesses to pages is the same as I currently have on the Motion TWiki but a dramatic difference is that the traffic is condenced to 50-60 hours per week (normal working day hours Monday to Friday).
  • There are now more than 20 webs and people ask for more to be created for specific projects. I have to say no. Subwebs will be a welcome feature here.
  • Users have to authenticate to read any topic. Users are LDAP authenticated. LDAP server is slow and it slows down browsing significantly (30 seconds delays seen) if all bin scripts are authenticated. Using Sessions and only authenticating ---auth scripts means LDAP is only queried once per session.
  • Registration is done only to give people a Wikiname. New confirmed registration feature with activation code is unwanted and will not be used.
  • Installing bug fixes can be a pain. When you download an updated Cairo you get a full package. If you just copy all the topics on top of the existing installation hell breaks loose. You wil overwrite essential topics like the preference topics and the TWikiUSers topic. So you carefully have to prepare an upgrade for hours. After Dakar is released I hope we get frequent bug fix releases that can easily be installed on a live server without any danger of overwriting preferences, or other essential settings topics. I never update a live server. I upgrade a mirror machine in the weekend. Then copy the topics that have changed while I upgraded from some bloke on weekend overtime to the mirror and copy it all back on the production server.
  • The TWiki installation is so essential that I have two machines running. One dual CPU dual harddisk in a raid server and an office type machine as a mirror backup. Additionally I backup to a backup server. If the production machine fails I can swich over to the mirror machine which has data not more than 24 hours old.

I would love to see more examples of installations added. Hope this helps TWiki developers making decisions in future in a way that does not sound like "I demand that you ... or I will go away and use another wiki".

-- KennethLavrsen - 15 Jan 2006

Thank you, thank you, thank you Kenneth for shedding light on the two (vastly different) use cases.

I would like to add a related note I posted in Bugs:Item1025 (with some additions):

In regards to backward compatibility vs innovation (or progress), I firmely believe that innovation can be done with compatibility in mind. I draw a line between between innovation and desired architecture. That is, some developers naturally think that backward compatibility hinders innovation, where I see innovation and nice architecture as complimentary things. Backward compatibility goes at the cost of "my preferred architecture", but not necessarily at the cost of innovation. I certainly would like to see our developers focus more on user centric innovation. That is, spend time on important innovations, such as a generic web services interface, a powerful rest interface, a J2EE/TWiki integration, syncronous edits, OO content access syntax, web based updates of TWiki/Plugins/apps, relational database backend, portlet integration, etc. All this can be done with a platform that is not ideal from an architectural point of view, but "good enough". Crawford made a lot of headway in improving the TWiki architecture in the DakarRelease. Innovative user centric enhancements will draw new users to the TWiki platform.

Lastly, if we create a nice architecure at the cost of compatibility we take away the barrier to switch to a competing product. If the cost of upgrading TWiki is the same as switching to another wiki we will inevitably lose users.

-- PeterThoeny - 16 Jan 2006

Thankyou Kenneth - this, unlike the other topic, is constructive - the other reads like a set of demands.

However, as should be obvious to all readers, I don't agree with Peter - I have found that backwards compatibility (especially in TWiki) has severely limited the ability to produce even a passable architecture, as there are constant hacks required to make the old hacked features continue to work as they used to.

I also think that TWiki has never had enough developers to support the approach that Peter is espousing - I guess time will tell when we see what happens with Edin*.

Innovation can definatly be done with compatibility in mind, but its much stronger if its not hamstrung by a total focus on compatibility - which is obviously what I feel is happening here.

I'd like to see the people that want to see TWiki focus more on User Centric innovation, to do it smile I also want to see it happen, but there have always been too many less sexy things to do.

I guess the crux is, that if you want to see a particular direction taken, you need to either do it, or find people who are also interested in doing it (or pay to have it done).

it does frighten me a little to read the list that Peter has above, and to realise that I've had a hand in every single one of those - most either to the point of proof of concept, or as internal TWiki Apps.

-- SvenDowideit - 16 Jan 2006

Like most TWiki developers, I am also a heavy TWiki user. My interests as a developer usually coincide with my interests as a user, though not always.

It was not by preference that I embarked on the re-engineering of the TWiki core to a more structured architecture. It was because the codebase had reached the end of it's useful lifetime, and I had to do something about it in order to explore my more interesting ideas. To refer to Peter's comments above, TWiki was clearly not "good enough", and hadn't been for quite a while. Unfortunately some of the design decisions that were made early in the TWiki project have had extremely negative knock-on effects. Attempts to deal with these effects is what has caused friction between some users and the dev team. Dakar is now barely "good enough" to build some more interesting stuff; but the re-engineering must go on. Without it, TWiki will quickly get bogged down again.

Backward compatibility has to be assessed on a supply and demand basis. There is no point continuing to produce bolts with imperial threads, when the whole of the industry has already moved on to metric. User feedback gives us the demand, and developers will supply the solutions. But if nobody expresses a demand for a feature, then there is no reason for developers to continue supporting it. Continuing to support features, especially undocumented features, just because someone might be using them, is nuts.

I really don't want to see TWiki in the position that we have to try and keep users through standing still. If that was an effective way of keeping users, then most of us would still be riding around on horses and shooting eachother with bows and arrows. By all means, make it easy for people to insure their investment. But do it by providing upgrade paths, not by hamstringing the next generation.

-- CrawfordCurrie - 16 Jan 2006

Crawford, you write: "But if nobody expresses a demand for a feature, then there is no reason for developers to continue supporting it." - I'm sorry, but I don't think this should be TWiki's guideline for development. This would ask all TWiki topic authors (not only those who install it) to issue their demand for every function they're using (if they're aware), for every upcoming release - otherwise the function might be discontinued.

Long-term reliability is an important factor if I choose a product for use, especially in a corporate environment. And there aren't too many wikis around which suit such environments.

On the other hand, I think that reasonable compatibility can be maintained without standing still. "Do it by providing upgrade paths" is the key: If we can upgrade topics, there's no harm when losing cruft.

And just to make sure: Dakar did go into a good direction as far as code refactoring is concerned. There are many places where I got really confused by Cairo code, and finally figured out what was intended by looking at Dakar.

For EdinburghRelease, I strongly opt for a Topic "Discontinued functions" where all incompatibilities are collected, isolated from the (lengthy) release notes. TWiki admins have to check for all of these if they desire but one single feature of Edinburgh, and it should be as easy as possible for them to do so.

-- HaraldJoerg - 16 Jan 2006

If I can allocate 100 precious hours for TWiki coding, what brings more value to the TWiki project overall: Externalize internal variables vs. creating user centric innovations? Such as a solid TWikiAjaxFramework, a generic web services interface, J2EE/TWiki integration, syncronous edits, OO content access syntax, web based updates of extensions/apps, relational database backend, portlet integration, and more. Needless to say, this needs to be done with perfomance, compatibility and usability in mind. I personally prefer TWiki to be ahead of the competition.

-- PeterThoeny - 31 Mar 2006

Sorry, Peter, but I fail to see much user centricness in the topics you are listing. Until now, questions like "How can I add my AJAX application to TWiki?" fail to pile up in the support web, and users are likely to not give a damn whether there's a relational database behind their Wiki or a flat file system.

"Performance" and "Ease of installation/use" seem to be dominant in the user centric area. "Needless to say, this needs to be done with performance" is the wrong way around: If AJAX, or OO content access, or a relational database, or whatever, helps to improve performance, then it is ok. Otherwise these features are rather wikimatrix centric buzzwords than user centric.

My users seem to especially like the ActionTrackerPlugin, the HolidaylistPlugin and a simple Bibliography application I've found in Sandbox. The competition still seems to have terrible difficulties to match that.

-- HaraldJoerg - 01 Apr 2006

I agree with harald here, None of the topic you mention are user-Centric. Actually, they´re VERY developer-centric.

-- RafaelAlvarez - 02 Apr 2006

We can differentiate several kinds of users: 1. twiki admins, 2. corporate users that also develop and 3. end users that do not develop. It can be confusing to call them all "users" or "customers". Some of the ideas Peter lists above have inpact on end users, while most will do something for developers. An ajax framework could provide a more seamless user interface (end users); OO content access could provide a foundation for easier to build applications (developing end users).

For most products the end user is most important: if the end user doesn't like it your product will fail. But as we have seen with Ruby on Rails (not an end user product) the developers are the most passionate advocates. So its not good to forget about developers either.

To let up keep the distinction between TWiki users, I propose these names:

  1. admin users
  2. user-developers
  3. end users

-- ArthurClemens - 02 Apr 2006

I agree to Arthur's classification of people working with TWiki. But I don't think it is necessary to call all of them "users". Keep it simple:

  1. Users are the people who create value by using TWiki as a collaboration platform.
  2. Admins are the people who get, and keep, TWiki installations running. Most of them are Users as well.
  3. Developers are the people who change TWiki. Most of them are Administrators as well, and I'd guess that almost all of them are Users.

The user-centricness of TWiki (like for most open source software) lives from the fact that almost all developers are users. The only way for non-developers to have influence on the user-centricness seems to be that they become developers (Kenneth is a prominent example).

I have no intention to forget about developers, but they usually know to care for their interests themselves. And I definitely don't want to stop anyone from implementing an AJAX framework. But I refuse to call the AJAX framework (or any framework) user centric. To be user centric, you have to consider the whole process up to the user: The user needs at least one concrete AJAX application to experience a seamless user interface. If we just ship a framework, then the developers' work simply isn't done, in a user's point of view.

I have to apologize for going so mad about this topic. Maybe I'll be really happy with an AJAX framework, or an topic object model. But I am a developer. I'd just like to reserve the precious term "user centric" to things which are visible to the user in the strict sense from above: of someone who wants to create value by using TWiki as a collaboration platform.

-- HaraldJoerg - 03 Apr 2006

I like Arthur's distinction of three user types.

Harald: On AJAX framework, the framework alone is for developers. It is user centric in a way Arthur described, TWiki developers and user-developers will create user-friendly applications once we have the framework. This brings value to end users. And to TWiki developers as end users because there is more choice / because there is more cool stuff that gets created (because TWiki gets more popular.)

I see this as a win-win situation.

-- PeterThoeny - 03 Apr 2006

I would go so far to say that if TWiki does not have an AJAX framework soon it will start loosing ground. Because the page paradigm

  • to refresh a page only to edit a piece of content
  • to refresh a page just to change the comment of an attachment
  • to refresh a page just to add a tag to the tags list
  • to refresh a page just to add the current page to My links
is going to look more and more unfriendly.

-- ArthurClemens - 03 Apr 2006

Please, don't deviate from the original meaning. I think that having an AJAX framework is great (that's why I created the rest script in the first place), but the main point is that an AJAX framework is NOT an user-centric feature. The kind of interfaces it enables IS a user-centric feature.

Along the same line, having pluggable authorization/authentication/identification implementations IS developer-centric, BUT think about the user that will need only to login in the Company Single Sign-On server and can use TWiki as an authenticated user, that is, can treat TWiki as just another part of the intranet. From that point of view, the pluggable implementation albeit being a developer-centric thing allows developers to build the very useful integration with corporate SSO system, and make users very happy. And let me tell you this is a major selling point in some corps.

So, I just is very unfair that AJAX is tagged user-centric while pluggable implementation of access/etc control is tagged as developer-centric. They are both developer-centric, but both enable developers to do very useful user-centric stuff.

-- RafaelAlvarez - 04 Apr 2006

BasicForm
TopicClassification TWikiCommunity
TopicSummary Developers and Customers - do they have common interests?
InterestedParties

RelatedTopics TWikiMission
Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2006-04-04 - RafaelAlvarez
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.