We've added a new feature making it easier to set up meetings and brainstorming sessions: new user accounts can now be created from the pages for setting up meetings and sessions, without having to set up the users on the User List first.
At the bottom of the list of attendees is a new hyperlink labelled "Create a new user". This asks for minimal information - e-mail address, first name, last name, initials - and then creates the user and adds them to the participants for the meeting/brainstorming session.
The user is given an automatic random password which is sent out to them by e-mail (saving the amount of information which you need to provide manually). The user also gets a very basic set of privileges on the system - these can be altered at your leisure via the normal User List.
Saturday, 14 July 2007
Sunday, 1 July 2007
NEW feature - graphs
We've added several graphing options to the system, mainly on the pages for analysing search results:
- Analysis of meeting search results
- Analysis of action point search results
- Analysis of workflow item search results
- Analysis of workflow item progress
Graphs are also available in one further place:
- Participant activity report for a brainstorming session
In each case, a graph icon is displayed at the top of each column of figures in the analysis. Clicking on the icon inserts a graph of the numbers, plus options for changing the style of the graph etc. And the graph gets included if you then choose the save the page as a PDF document.
This isn't intended to handle every possible graphing scenario. You can continue to build bespoke graphs (and reports) yourself by downloading list results in CSV form, into Microsoft Excel etc, and graphing it there.
Friday, 15 June 2007
Why is progress in computer software so glacial?
It seems that we're still living out the tail-end of Romanticism. Nowhere is this more evident in the UK than in the popular obsession with cookery, and everything which appertains to it. Cooks, cooking, and cookery books dominate the bestseller lists and the TV schedules. It's the country's prime artistic medium and means of self-expression, and the public is infatuated with celebrity chefs and their dymamic, anti-conventional, artist-hero personas. Gordon Ramsay is Byron, and Heston Blumenthal is Shelley (in the sense of Shelley's experiments with electricity and magnetism, not his interest in proto-socialism, casual sex with jailbait, and advocacy of vegetarianism).
Behind the scenes, of course, things are rather different from the romantic-hero image. Deluxe restaurants are slickly-run operations, far more regimented and rigorous than the average business. The working day is very long, and precisely scheduled. There are complicated and well-protected supply chains. Marketing is vital. There's a clear line of command, and everyone's job is a small cog in the big machine - clear, repeatable, endlessly repeated. The temperatures are sweltering but, in spirit, the chef de cuisine, sous chef, chef de partie, rotisseur, second chef, aboyeur etc. all need to be "cucumber-cool machine minders" (Auden, Horae Canonicae).
Apart from a complete lack of public interest, the position in IT is almost identical. The public perception - inasmuch as there is one - is of the lone hacker, the guru. The reality is a series of highly segmented jobs, of increasingly minute specialisation. No one "knows about computers", or is competent to do more than a handful of jobs in the field. The system administrators can't program, and the programmers would cause utter chaos if they were allowed to fiddle with your company's IT infrastructure. Each of the programmers has an area of specialisation about which the others know little or nothing. The boss can't do any of what his team does. (The more someone earns in IT, the less likely they are to be able to fix your computer.)
In this segmented world, most of the larger entities which produce software - either for internal use, or for sale - separate out the jobs of designing the software and writing the actual code. (Most of them segment things still further, and have one person to identify a "business need" and another to design the software which meets that need. Someone else then codes it. Salaries go in descending order.)
These designers (mostly) can't write code. They (mostly) know no more about programming than you do - barring a sort of cargo-cult knowledge acquired from sitting next to the bearded blokes in T-shirts every day.
Therefore, the designers don't know what's technologically possible and impossible. They only know what they've seen done before. Their designs are necessarily mimetic. They'll produce solid, sensible designs in an accepted mould all day long, but they're never going to innovate. Their employers like this. They're risk-averse. That's why they segment the jobs. Which is fine for them, but it means that progress in computer software en masse is glacial.
Therefore, innovation and improvement in computer software almost always comes when there's no - or very, very little - separation between the people designing the software and the people writing the code. That tends to imply small, young companies - early Apple, or early Google. They keep the fire burning as they grow larger by buying other small, young companies (though Google have tried to institutionalise the phenomenon through their famous "20% time").
Or Matchpeg. We'll never have a job title including the words "Analyst" or "Architect". "Product Manager" is also verboten. Deliver results.
(Part of an occasional series on matters technological. It beats doing real work.)
Behind the scenes, of course, things are rather different from the romantic-hero image. Deluxe restaurants are slickly-run operations, far more regimented and rigorous than the average business. The working day is very long, and precisely scheduled. There are complicated and well-protected supply chains. Marketing is vital. There's a clear line of command, and everyone's job is a small cog in the big machine - clear, repeatable, endlessly repeated. The temperatures are sweltering but, in spirit, the chef de cuisine, sous chef, chef de partie, rotisseur, second chef, aboyeur etc. all need to be "cucumber-cool machine minders" (Auden, Horae Canonicae).
Apart from a complete lack of public interest, the position in IT is almost identical. The public perception - inasmuch as there is one - is of the lone hacker, the guru. The reality is a series of highly segmented jobs, of increasingly minute specialisation. No one "knows about computers", or is competent to do more than a handful of jobs in the field. The system administrators can't program, and the programmers would cause utter chaos if they were allowed to fiddle with your company's IT infrastructure. Each of the programmers has an area of specialisation about which the others know little or nothing. The boss can't do any of what his team does. (The more someone earns in IT, the less likely they are to be able to fix your computer.)
In this segmented world, most of the larger entities which produce software - either for internal use, or for sale - separate out the jobs of designing the software and writing the actual code. (Most of them segment things still further, and have one person to identify a "business need" and another to design the software which meets that need. Someone else then codes it. Salaries go in descending order.)
These designers (mostly) can't write code. They (mostly) know no more about programming than you do - barring a sort of cargo-cult knowledge acquired from sitting next to the bearded blokes in T-shirts every day.
Therefore, the designers don't know what's technologically possible and impossible. They only know what they've seen done before. Their designs are necessarily mimetic. They'll produce solid, sensible designs in an accepted mould all day long, but they're never going to innovate. Their employers like this. They're risk-averse. That's why they segment the jobs. Which is fine for them, but it means that progress in computer software en masse is glacial.
Therefore, innovation and improvement in computer software almost always comes when there's no - or very, very little - separation between the people designing the software and the people writing the code. That tends to imply small, young companies - early Apple, or early Google. They keep the fire burning as they grow larger by buying other small, young companies (though Google have tried to institutionalise the phenomenon through their famous "20% time").
Or Matchpeg. We'll never have a job title including the words "Analyst" or "Architect". "Product Manager" is also verboten. Deliver results.
(Part of an occasional series on matters technological. It beats doing real work.)
Monday, 11 June 2007
Why doesn't web-based software make use of the right mouse button?
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).
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).
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.
Subscribe to:
Posts (Atom)