How idiot-proof can SMF be made?

Started by MrPhil, April 29, 2010, 10:54:06 AM

Previous topic - Next topic


Quote from: shentino on July 26, 2010, 05:29:33 PM
Personally, I think that refusing to read documentation that's clear and well written should be considered suicide.
Well........... how often have you found documentation that's clear and well written and complete and well organized? Damned rare, in my experience, especially with Open Source projects.

Let's look at it from the viewpoint of a user. An "idiot" user. They want to do something, so they fire up the Admin section, or whatever, and try to do what they want. They are not necessarily going to go searching for documentation first. Even if they do find documentation, did they have to hunt for it, or was it easily available? If they could find it without too much trouble, was it clearly organized, so they could find what they wanted without having to read War and Peace from cover to cover? Some sort of "help" buttons linked to the appropriate documentation sections should ideally be scattered throughout a page. Help is at hand, and you're taken directly to the pertinent help, and you have the ability to start browsing around via links to other help text. That would be the most useful documentation, and the most likely to be used (even by idiots). You don't want to clog up a task with instructions mixed in with everything else, but you don't want a user to have to drop everything and get into a different mindset to go looking for answers. By the way, documentation of any kind should always include a "task oriented" or "cookbook" section -- that's where most users will head first when confronted with a task they need to do.


Quote from: 青山 素子 on April 29, 2010, 12:41:26 PM
One way to solve the problem is to go completely object-oriented. To add functionality, you can extend a class. Of course, this has a huge potential for killing modification developers since they would all have to wrap their heads around your object structure and most of the people developing modifications for SMF are not anywhere near experienced or dedicated enough to learn all the framework required for even a small change. With this method, you also have the potential for performance issues

The next possibility is to add "hooks" like other products do. Unfortunately, unless you design these smartly in the flow or add something for each line, it becomes restrictive as to what modifications can do when using that system. Heck, even with being smart in location or just scattering things over the place, you'll still likely run into situations where you need something else.

Yet another possibility is to support both "hook" and an inline-edit methods. The problem here is that you will get a lot of people doing direct code edits and you'll run into the same problems of conflicting code edits.

In conclusion, the best solution for flexibility without conflicts is going the object-oriented way, but you also cut down the number of people who will be able to work in that model. If you want to allow flexibility while encouraging beginners to customize things, you'll almost have to allow direct code edits and the possible issues that can bring.



"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams
SMF 2.0.1
SimplePortal 2.3.3