A brief investigation of why it's so rare to see web applications which make use of the right mouse button. Yes, there are lots of reasons not covered here, and numbers #1 to #3 are pretty obvious. Part of an occasional series on matters technological. It beats doing real work.
Reason #1: effort
Handling the right mouse button in web pages is a bit fiddly. Some developers don't know how to, or can't be bothered. It's lots more work than just putting in a hyperlink.
Reason #2a: transient user base
On the whole, people spend much more time using desktop application A than any web-based application B. There's a pretty small number of business-critical, use-it-every-minute-of-the-day web applications. Very few clock up even an hour of usage per user per week. In other words, very few web applications have any "power users".
The traditional problem in desktop software is how you advertise to the user that right-clicking is available.
This problem gets much harder when you're dealing with a web application which people only use occasionally, haven't been trained on, and want to be able to use "intuitively". You don't have time or receptiveness on your side to explain that right-clicking is available.
Reason #2b: not what users expect
And so there's a feedback effect. Developers don't put right-clicks into web-based software. Therefore, users don't expect them. Therefore, developers don't put them in.
Reason #3: blame Apple
Everyone demonstrates web-based applications running on Macs. Many (most?) Macs have single-button mice. Ctrl+click is a pain in the neck.
Reason #4: effort (part 2)
Firms which produce web-based software tend to have less formal documentation procedures than firms which produce desktop software. Documentation is not cool; it's not Web 2.0.
The alternative to providing a right-click (e.g. plus pop-up menu) will often be a whole extra configuration screen/dialog. This extra screen would need to documented and designed in advance, approved, coded, sent back for re-design when the uber-product manager doesn't like it, re-approved, re-coded, and probably needs all sorts of extra pages in the help file as well.
In other words: if your documentation procedures are strict, putting in a right-click is generally less hassle than the alternatives. So, desktop software tends towards having a minimal number of "busy" screens (whereas web applications tend towards lots of simple screens, for a number of other reasons including minimising/shaping bandwidth usage).
Monday, 11 June 2007
Thursday, 7 June 2007
NEW feature - analysis of workflow item progress
We've added a new feature to the analysis of workflow items. In addition to analysing the results of a search by current owner, creator, workflow stage etc. you can also now analyse the progress of the workflow items.
After doing a search for workflow items you simply click on the "Item progress" menu-bar link. This shows how long the items have spent at each stage, and with each person. It's obviously a simple and very quick way of highlighting bottlenecks in your processes - people in your team who are overloaded, processes which are inefficient etc.
Like all such pages within the system, the progress analysis can be saved as a PDF document.
Monday, 28 May 2007
BMW functionality
(Part of an occasional series on matters technological. It beats doing real work.)
Before we started Matchpeg, we used to be Terribly Important People. We used to think nothing of donning our superhero garb in the nearest phonebox, and then leaping into a presentation with senior executives to sell them hundreds of thousands of pounds/dollars/euros of software and services at a time.
Like everyone else, we built our fair share of BMW functionality - not a reflection on the marque, but a comment on the sort of cars driven by the sort of people we were presenting to.
BMW functionality looks very pretty - albeit in a standardised, Stock-Option Chic kind of way - and it's not totally pointless. (A typical example is a ray-traced pie chart representing three numbers so simple that their relative proportions could be visualised, without graphical aids, by a child of seven.)
You're in a meeting where you're presenting the BMW functionality. You know that no one will ever actually "use" it. Even the users know that they'll never actually use it. But they're not in the room. You're presenting to the company's senior executives, and an 80/20 rule applies: they make 80% of the purchasing decision, but they're going to clock up at most of 20% of the eventual usage of the system.
At best, this is neutral: the BMW functionality is, in effect, part of your marketing (not your software); it helps to sell a fundamentally good system which deserves to do well; and it doesn't have any adverse impact on the quality of the system.
At worst, it's actively harmful: the time spent on the BMW functionality could and should have been spent on making the actual software better; and/or other, useful features are discarded or compromised in order to squeeze in what's effectively your sales pitch which the lowly users then have to live with day-by-day for the next n years.
This is less common on the web, because relatively few web-based applications are sold face-to-face. But there's still pressure to make sure that your software produces a great screenshot, and there's often tension between what produces the best screenshot and what produces the best functionality. (As an innocuous version of the same phenomenon, count the number of web-based applications which are demonstrated using Mac screenshots despite the fact that 97% of their users will be running Windows. Yes, we do this. Everyone does. It's the harmless end of something much more serious.)
What does all this lead up to?
We took a vow when starting Matchpeg: no BMW functionality. Deliver results.
Before we started Matchpeg, we used to be Terribly Important People. We used to think nothing of donning our superhero garb in the nearest phonebox, and then leaping into a presentation with senior executives to sell them hundreds of thousands of pounds/dollars/euros of software and services at a time.
Like everyone else, we built our fair share of BMW functionality - not a reflection on the marque, but a comment on the sort of cars driven by the sort of people we were presenting to.
BMW functionality looks very pretty - albeit in a standardised, Stock-Option Chic kind of way - and it's not totally pointless. (A typical example is a ray-traced pie chart representing three numbers so simple that their relative proportions could be visualised, without graphical aids, by a child of seven.)
You're in a meeting where you're presenting the BMW functionality. You know that no one will ever actually "use" it. Even the users know that they'll never actually use it. But they're not in the room. You're presenting to the company's senior executives, and an 80/20 rule applies: they make 80% of the purchasing decision, but they're going to clock up at most of 20% of the eventual usage of the system.
At best, this is neutral: the BMW functionality is, in effect, part of your marketing (not your software); it helps to sell a fundamentally good system which deserves to do well; and it doesn't have any adverse impact on the quality of the system.
At worst, it's actively harmful: the time spent on the BMW functionality could and should have been spent on making the actual software better; and/or other, useful features are discarded or compromised in order to squeeze in what's effectively your sales pitch which the lowly users then have to live with day-by-day for the next n years.
This is less common on the web, because relatively few web-based applications are sold face-to-face. But there's still pressure to make sure that your software produces a great screenshot, and there's often tension between what produces the best screenshot and what produces the best functionality. (As an innocuous version of the same phenomenon, count the number of web-based applications which are demonstrated using Mac screenshots despite the fact that 97% of their users will be running Windows. Yes, we do this. Everyone does. It's the harmless end of something much more serious.)
What does all this lead up to?
We took a vow when starting Matchpeg: no BMW functionality. Deliver results.
Tuesday, 15 May 2007
NEW feature - notes on workflow items owned by someone else
Bowing to very vocal demand, we've added a new feature to the workflow system: the ability to add a note to a workflow item which you don't currently own. (It continues to be the case that the current owner is the only person who can change the workflow item in any way.)
The ability to add these notes is controlled by the workflow definition. This switch is turned off for all existing workflows. If you want to take advantage of this new feature, you need to edit your existing workflow definitions and turn the switch on.
After doing so, anyone who's not the current owner of a workflow item is able to add a note to it using the new box at the bottom of the item overview page.
Sunday, 13 May 2007
Project management
(Part of an occasional series on matters technological. It beats doing real work.)
We've been having some internal wrangling here at Matchpeg Towers about project management/software development methodologies (not much wrangling - we're all fugitives from organisations which like signatures in triplicate on everything).
Matchpeg is essentially in the retail software business. We sell tools at low cost, in large quantities, to happy customers who we rarely have any un-automated contact with. We do very little bespoke work. We don't really have "clients".
There's a polarised debate all over the web about the relative merits of waterfall (relatively linear, relatively traditional) software development processes versus more agile methodologies.
Waterfall doesn't work for us. It's not that we're a bunch of laid-back hippies - agile doesn't work for us either.
The problem with both is most concisely represented by the Agile Manifesto. Notice anything about this? (Leaving aside the fact that it reads like a Miss World contestant's pledge to seek out world peace and a cure for cancer.)
The references to customers are both in the singular, not to "customers" plural. We're in the retail software business. We have lots of customers. And they're so diverse that you can't boil them down into a single representative entity called "the customer" (or even "The Customer").
(The same failings can be found in things like the official PRINCE2 material: same assumption of a single customer; same assumption of a single entity paying for the project; same assumption that there's a contract.)
In short, our experience is that no well-known software development process translates at all well to the retail world. They all seem to stem from a founder's experience of in-house development for a large company, or bespoke development for a single (usually large) client. Using a popular term in IT, these methodologies don't "scale" well. They make all sorts of assumptions which stop working when you're dealing with a number of diverse customers, each of whom isn't guaranteeing to pay you anything.
These methodologies are created by consultants in order to perpetrate consultancy. They're for use with "clients", not "customers".
--
On a related note, we're bemused by the way the debate between waterfall and agile is usually presented: an either/or choice, generally accompanied by comments such as "waterfall is so lame".
Instead, it seems to be about risk/reward profiles. A question such as "Which is better, waterfall or agile?" looks as meaningless as "Which is better, stocks or bonds?" The answer depends on your circumstances and what you're trying to achieve.
As a very general rule - to which there are, yes, countless exceptions - the anecdotal reports on the web tend to indicate that agile methodologies offer the prospect of better returns (faster development) at the risk of greater loss (complete anarchic breakdown of a project into marauding bands of developers).
It's not a coincidence that waterfall methods tend to be preferred by larger, older firms, and agile tends to be preferred by smaller, newer firms.
If you're a small company just starting up, you have to take risks. You gravitate towards agile because you're not going to get anywhere by being dull-but-steady. Older companies - particularly public companies - don't and can't have the same appetite for risk. Everything militates against it: the shareholders want predictable returns, the employees want to keep their well-paid jobs. The potential additional reward doesn't justify the additional risk; the reward is too incremental, and the risk is too absolute.
The really nasty fights start when the incentives and risk-tolerance of the business owners are different to the incentives and risk-tolerance of the people running projects for them. This works both ways: an impetuous CEO who finds that he's hired a pen-pushing dullard of a project manager, or a cautious board which has landed itself with a bunch of mavericks who won't be significantly affected if they cause their project (or even the entire firm) to implode.
We've been having some internal wrangling here at Matchpeg Towers about project management/software development methodologies (not much wrangling - we're all fugitives from organisations which like signatures in triplicate on everything).
Matchpeg is essentially in the retail software business. We sell tools at low cost, in large quantities, to happy customers who we rarely have any un-automated contact with. We do very little bespoke work. We don't really have "clients".
There's a polarised debate all over the web about the relative merits of waterfall (relatively linear, relatively traditional) software development processes versus more agile methodologies.
Waterfall doesn't work for us. It's not that we're a bunch of laid-back hippies - agile doesn't work for us either.
The problem with both is most concisely represented by the Agile Manifesto. Notice anything about this? (Leaving aside the fact that it reads like a Miss World contestant's pledge to seek out world peace and a cure for cancer.)
The references to customers are both in the singular, not to "customers" plural. We're in the retail software business. We have lots of customers. And they're so diverse that you can't boil them down into a single representative entity called "the customer" (or even "The Customer").
(The same failings can be found in things like the official PRINCE2 material: same assumption of a single customer; same assumption of a single entity paying for the project; same assumption that there's a contract.)
In short, our experience is that no well-known software development process translates at all well to the retail world. They all seem to stem from a founder's experience of in-house development for a large company, or bespoke development for a single (usually large) client. Using a popular term in IT, these methodologies don't "scale" well. They make all sorts of assumptions which stop working when you're dealing with a number of diverse customers, each of whom isn't guaranteeing to pay you anything.
These methodologies are created by consultants in order to perpetrate consultancy. They're for use with "clients", not "customers".
--
On a related note, we're bemused by the way the debate between waterfall and agile is usually presented: an either/or choice, generally accompanied by comments such as "waterfall is so lame".
Instead, it seems to be about risk/reward profiles. A question such as "Which is better, waterfall or agile?" looks as meaningless as "Which is better, stocks or bonds?" The answer depends on your circumstances and what you're trying to achieve.
As a very general rule - to which there are, yes, countless exceptions - the anecdotal reports on the web tend to indicate that agile methodologies offer the prospect of better returns (faster development) at the risk of greater loss (complete anarchic breakdown of a project into marauding bands of developers).
It's not a coincidence that waterfall methods tend to be preferred by larger, older firms, and agile tends to be preferred by smaller, newer firms.
If you're a small company just starting up, you have to take risks. You gravitate towards agile because you're not going to get anywhere by being dull-but-steady. Older companies - particularly public companies - don't and can't have the same appetite for risk. Everything militates against it: the shareholders want predictable returns, the employees want to keep their well-paid jobs. The potential additional reward doesn't justify the additional risk; the reward is too incremental, and the risk is too absolute.
The really nasty fights start when the incentives and risk-tolerance of the business owners are different to the incentives and risk-tolerance of the people running projects for them. This works both ways: an impetuous CEO who finds that he's hired a pen-pushing dullard of a project manager, or a cautious board which has landed itself with a bunch of mavericks who won't be significantly affected if they cause their project (or even the entire firm) to implode.
Friday, 11 May 2007
NEW feature - removing brainstorming suggestions in real-time
We've added a new feature to brainstorming suggestions, particularly designed for use when running sessions in real-time. In addition to the full transcript editor, the organiser of a session can now delete ideas from the session, during the brainstorming stage, by clicking on the new grey cross icon which is displayed to the right of each idea.
This simply deletes the idea from the session. It has exactly the same effect as using the transcript editor to remove the idea. Like the transcript editor, only the session organiser is allowed to do this (and only they get given the icon for doing so.)
Thursday, 10 May 2007
NEW feature - user groups
We've finally added a feature which we'd had in mind for a long time, and which several customers then prompted us by asking for...
You can now define a group of users (i.e. a list), and use it as part of a workflow definition. For example, you can define a "Customer Services" team, and have customer enquiries and requests being allocated to that team rather than to a specific individual.
It remains the case that every workflow item is always assigned to one specific person: if the workflow definition says to assign the item to a group, the system picks an individual from the group and assigns the item to them.
The definition of a user group lets you define how work is shared out amongst the group members: simple round-robin allocation of tasks, allocation based on who has the fewest items in their workflow queue etc.
You define user groups from the user list - i.e. click on "User list" from the Dashboard, and then click on "User groups". Only administrators are allowed to change (or delete) groups.
Groups can then be used anywhere within the workflow system where it asks who to assign a workflow item to.
As ever, full information can be found in the help file. We particularly recommend looking at the section entitled "Using groups as aliases".
Subscribe to:
Posts (Atom)