On 2/11/2011 12:59 AM, Johannes Meixner wrote:
Hello,
On Feb 10 21:31 Marc Chamberlin wrote (excerpt):
What ... many Linux zealots fail to understand, is that half the battle of designing a well design tool(s) is that it is the job of the designers and programmers to make it easy for newcomers ...
Basically there are no extra designers for most Linux software. Basically it is the "Linux zealots" who make most Linux software.
It is a contradiction in itself to demand that "Linux zealots" should make their software easy for newcomers because they cannot.
They would need newcomers who are willing to spend time and energy to contribute real value and work together with them over a longer time and help them to understand how their software looks from a newcomer's point of view.
Unfortunately there is not much of those contribution.
Johannes - Your thoughts are very welcomed, but I am in strong disagreement with you also. Getting newcomers to provide feedback to developers can be easily accomplished if tools are designed and developed to MAKE it easy. Feedback is THE most important tool a developer can have. With it, he can improve his/her product immensely, and thus provide the multi level support needed for all competencies. How often have I wished to see a feedback button located right under the Help button! That alone shows the developer(s) care. (Command line designers/zealots could also put in a 'feedback' parameter for their tools which would solicit and forward comments to the designers. Makes wrapping such tools with thoughtful GUI's easier also.) I recognize that you will argue, that developers will fear being overwhelmed then. Maybe in the beginning, right after a tool is released, that will happen. But if developers take time to listen, adjust the product and correct the errors, that rate will taper off. Tools like GUI based Bugzilla can also mitigate some of this, via their voting process. Trouble is, most newcomers cannot even FIND, or even are aware of, a bugtracking tool that supports a particular tool, or a forum such as this one where help can be solicited. So, BUILD IT IN to the product! Put it in the HELP design and lead the user to it. In other words put it up front so the newcomers and others CAN discover/use these mechanisms. Your complaint about the lack of getting feedback and help from newcomers again boils down to how the tool and its support subsystem was designed. Usually badly....
Instead there are mostly only complaints when something does not work which does not really help the developers.
Oh YES, but complaints are extremely valuable, IF AND ONLY IF you take the time to LISTEN and understand where the problem really lies, and take the time to then correct it. Most complaints are very likely to boil down to the fact that the user does not understand how to use a tool. By correcting, I don't mean correct the user, but rather correct the tool. Answers, such as what Anton gave me - RTFM - is so wrong on so many levels. Anton complained that I was beating my head against a wall because I was unwilling to change my approach to a problem I was trying to solve. I disagree. NO, it is the developers who are beating their heads against a wall, insisting that users RTFMs, designing tools in a now 30 year old fashion, and not being willing to LISTEN to users and change their approach in software design and development. I repeat my earlier statement, if you want less complaints, design the tools to be teachers and guides, provide easy feedback systems that allow corrections to take place, as well as implementers of functionality.
Implementing features is one thing, designing for usability is quite another.
Yes.
I look forward to your valuable contribution regarding software design and usability.
And you are getting it, right now! Anton said that I, and users in general, have to learn how to do things the "Linux way" Fine. I just want that "Linux way" to include all levels of user competencies, not just experts who have a broad width and depth of understanding the Linux architecture and the associated tools limitations. That requirement becomes a barrier to entering the Linux world. Where are the "Linus Torvold's" who set the standards for the look and feel of Linux and it's tool sets? I know Linus has been one of the main gatekeepers for the kernel itself, but what about the rest of the system? Who make's the decision about what tools get included in a distribution's packages? At some level this has to be happening, and this is where a "standard" of acceptance should be developed, and tools judged on how well they meet those standards. Then roadmaps can be laid out for volunteers to pick and choose what to work on, and tool development guided towards becoming more and more usable for more and more users...
Until you learn the difference, and understand that there are multiple levels of target audiences competency levels, please stay out of software design and development.
Wow!
If I understand you correctly, you say that many free software developers should "stay out of software development".
In this case I assume with this kind of mind-set nobody would like to listen to what you will contribute regarding software design and usability.
No, you do not understand me correctly. I have nothing against free software developers, and much appreciate their time and efforts. But they need to be guided as well, and shown the way towards how to create excellent software. What I was really trying to say is that if you are unwilling to change your software development attitude, and design for usability instead of just functionality, then don't design at all. That attitude is doing far more harm than good for computers in general. I have taken a lot of time to try and explain, with examples, of what sort of thinking is required, (got off on a huge tangent here!) if Linux ever wants to evolve into a really superior OS and a cool environment for ALL of it's users. I am willing to help, I have been in this business for a long time now and seen some really neat examples of what works and what doesn't. I have also been a teacher, a very humbling experience, and the one thing I have learned is you cannot pigeon hole users and force them into fast learning processes that require a broad width of understanding of computer science. You cannot simply rely on requiring users to read lots of external dry documents in order to use a particular tool. You try and you will fail. That is archaic thinking and there are far better ways.... I hope a few developers/readers are really listening and doing some soul searching. I will summarize - Successful software development is going to be judged in terms of usability. Functionality is 10% of the battle, and currently gets 90% of many if not most software developer's focus. That focus HAS to change to be closer to 50/50. By functionality I am referring to those features/software elements that are focused on making the tool perform its basic job. By usability I am referring to those features/software elements that are focused on making it easier for a user to use the tool, provide feedback to developers, guide and teach painlessly, and finally make it a joy for the user to use said tool.
Regards Johannes Meixner
Regards also... Marc Chamberlin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org