His argument was that twitter was not and should not be used as a tool for conversations, but more for ‘announcements’. Now his argument is not without merit, if you follow many followers or take your eye of your twitter app for a second then you can quickly lose the conversation thread, however he seems to be implying that you should not use twitter in this way, full stop. Problem with that is his argument suggests that there is a set if rules for using twitter and these should be followed by all users, this is wrong, for twitter and all other products or services being developed. There are no rules there are however behavious patterns that define how users adapt a service to their needs, and its this that makes the web(2.0?).

If twitter or any service is to survive then it has to evolve, just like people.

Argument is as follows:

As you build a site( for site you can substitute webapp /service /product/whatever but I’ll use app for ease of use) you have an idea of the users that you need to talk to. If your smart you talk to these users and ask them what they want, try to use this to identify what they actually need and design a solution that fits this need, you of course test it with representatives of these users and make adaptations to the site before go live.

On go-live you are confident you have a successful site in the making and sit back, update content maybe add functionality in later phases of the site as per the development roadmap and generally watch the site grow.

Trouble is the users evolve, they mature in their use of your site , their needs develop as they get comfortable they develop new ways of using the what you have delivered in ways you never considered, and, if you don’t adapt to these needs then your site will whither and die, and your visitors find a new site that fits their new behaviour better.

you need to monitor how your users try to *abuse* the functionality you have supplied and adapt the site to make it easier for them to achieve their new activity.

This is <tech-volution /> (yes i made this up)

So back to the original point, and Roberts assumption that Twitter is to say that twitter is not for conversations, this is a mistake and I’m afraid, wrong, if this where true then no-one would use twitter for conversations, the problems with using the service in this way would make it unusable, in the same way as you don’t use a fork to eat soup.

Twitter may not be ideal for conversations , it may be tricky but its not wrong, and it would not surprise me to hear that the folks at twitter are planning spend some of their $50 million to release new features for the service that allows threading for conversations, that is if tweetdeck or twhirl (insert twitter client here) don’t get there first,

That’s tech-volution.

ezvx4q29fg

Users.., what are ‘users’ when discussing CMS requirements, and are they the same as website users?

In a traditional sense users are often regarded as the ‘users’ of a website, UX professionals talk about user testing and user centered design processes, but when it comes to CMS the user can be seen as the ‘site; user or the CMS user, each with very different needs and thus differing impacts on your requirements exercise. It’s important therefore to make sure that you are talking about the same ‘audience’ and that you accurately address their needs.

Site users, (visitors) need to be able to find information quickly and need navigation accessible content, they may ‘use’ the functions of the site in the process of finding content but referring to them as users (in the CMS context) clutters the message. Navigation, clarity, language findability structure and design make for the site visitors experience.

The needs of the CMS user however is concerned with editing interfaces, categorization and linking, they need workflow and accessibility checkers, they need to know who did what when and how, the kind of stuff that CMS (WCMS) should do well.

Most of the time the description of the feature needed will be itself explanatory. However you should never allow ambiguity and assumption into your requirements study. (Similarly words such as ‘solution’ ‘system’ and ‘service’ should also be avoided in this context.

For example

“The solution should be accessible to users with disability”…means what exactly?

Then we get to audiences, now these are different again. An audience, in this instance, could be defined as category or group of users (or visitors) who share characteristics, interests or experience levels.

Parents, teaches and students are all audience types, as a parent I am a visitor to my boys school website. The teacher’s who create the site with their CMS is a CMS User,

Users, visitors and Audiences are therefore interlinked, but have differing views of the solution you are defining, if you are going to meet these needs you need to make sure that you and your project sponsor / customer have a shared understanding of these differences and needs to avoid the ambiguities and, even worse assumptions that add risk to your project.