I hear two different discussions on usability for OSS software. Discussion boards like this often praise this kind of work, but when you get to discussions with the people that develop the applications, it's a much much harder sell because everyone thinks they know what usability is.
Recent discussions on http://usability.kde.org and the desktop subproject for Debian are some examples of a refusal to get beyond comments like "Hey, check out my new widget!" and "Look, it's skinnable!"
not that I'm bitter or anything....
Without trying to learn more about usability techniques from people that make a living at it, we will be running around wasting our efforts on useless chatter.
There was no database involved, they were stroring info in plain text. ( a.txt file !)
The only tools needed was Netscape (lynx would have worked as well...)
We are currently establishing an SDLC process where a consultant was brought in to get us going. He started by creating a 'framework' with the managers of the development group. This framework was split into several groups that were to come up with the details on each of the sections of our framework.
Using this description, it all seems reasonable. However, the execution failed. Our framework was tainted because instead of facilitating our managers to create a process they could buy into, it was more of 'it's only right if the consultant thinks of it or fits into their pre-conceived framework'. The group meetings with the developers was worse, we rebelled. The first week's meetings were bad and we complained. The next weeks meetings were worse, and we complained more. The beginning of the third week saw the halt to all the meetings.
Our CIO has realized that the meetings are not helpful mainly due to the lack of facilitation skills of the consultant. Everyone realizes the need for an established process:Error reduction, consistent development standards, ease in adding new developers to a team, etc.
This week, we're going to try a 'do and review' approach, rather than a 'cuss and discuss' approach.
Wish us luck.
Slashdot Mirror
I hear two different discussions on usability for OSS software. Discussion boards like this often praise this kind of work, but when you get to discussions with the people that develop the applications, it's a much much harder sell because everyone thinks they know what usability is.
Recent discussions on http://usability.kde.org and the desktop subproject for Debian are some examples of a refusal to get beyond comments like "Hey, check out my new widget!" and "Look, it's skinnable!"
not that I'm bitter or anything....
Without trying to learn more about usability techniques from people that make a living at it, we will be running around wasting our efforts on useless chatter.
They did damage control. Otherwise, if securitywatch.com had sent the report first, it would have been worse.
There was no database involved, they were stroring info in plain text. ( a .txt file !)
The only tools needed was Netscape (lynx would have worked as well...)
Their service wasn't hacked into... They allowed their data to be plainly viewed with a URL (see comp.security.misc for detials).
We are currently establishing an SDLC process where a consultant was brought in to get us going. He started by creating a 'framework' with the managers of the development group. This framework was split into several groups that were to come up with the details on each of the sections of our framework. Using this description, it all seems reasonable. However, the execution failed. Our framework was tainted because instead of facilitating our managers to create a process they could buy into, it was more of 'it's only right if the consultant thinks of it or fits into their pre-conceived framework'. The group meetings with the developers was worse, we rebelled. The first week's meetings were bad and we complained. The next weeks meetings were worse, and we complained more. The beginning of the third week saw the halt to all the meetings. Our CIO has realized that the meetings are not helpful mainly due to the lack of facilitation skills of the consultant. Everyone realizes the need for an established process:Error reduction, consistent development standards, ease in adding new developers to a team, etc. This week, we're going to try a 'do and review' approach, rather than a 'cuss and discuss' approach. Wish us luck.
This is one of the forgotten hacks.
I just hope that I can be the same age of Python someday...
but isn't XML represented as text???