Robert Kaiser wrote:
Rufus wrote:
...if users aren't being considered in a development path, that's a
pretty inconsiderate way to "develop" a product.
I fully agree. The picture is just not that simple usually, and most of
the time it's tradeoffs between listening to different user bases, or
tradeoffs causing to get some large improvements while losing some
smaller thing(s) or tradeoffs between getting something shipped and
being perfect.
Usually, when you create something, you have to make some hard decisions
involving such tradeoffs, and the same if true here. And that's what
project management is all about. If you have ever done such a "job", in
business or in non-profit space, you probably know what I mean.
We're trying our best to deliver the best software we can - that may
sometimes not be enough for everyone, but believe me, we're trying hard
to deliver the best thing we can do for our users.
In terms of SeaMonkey 2, those decisions were in a few cases between
letting the project as a whole die or replacing some old feature with a
new feature that works differently. How would you decide in such a
situation?
Robert Kaiser
The above pretty much sums up what I do for a living for software driven
human interfaces for systems...keep in mind, I'm not a coder - I'm an
evaluator/configuration manager. In my professional world I have a user
base that has formal training requirements and the requirement to
maintain skillset - there are no such user requirements for using SM,
and so IMO maintaining a stable configuration with an informative
interface is of paramount importance if the team wishes to adequately
service the widest user base.
Here are a number of points for consideration:
1) make "under the hood" security oriented implementations without
impacting current user interface. And I mean ZERO impact or change to
the interface - make them user transparent.
2) poll users as to which interface changes are acceptable to the widest
number of users before making interface changes - particularly big ones,
like deleting the Forms Manager; or very notable ones like reducing the
sizes of user input areas/presentations.
3) never make an interface change without explaining just what has
changed in the text of a dialog box for the new functionality, or in the
remaining box of the remaining function - no trade or revision without
accompanying explanation, at least at the first introduction of that
trade. Coders need to remain aware SM must both inform and serve.
4) adopt a schedule for release and release fewer changes per cycle -
this could be done on a shorter cycle, allowing for more releases.
5) adopt a longer release cycle for major changes to allow user polling
and beta test of (all) pending implementations prior to formal release -
this would fit a longer cycle with fewer releases.
6) adopt a criteria for scrap/elimination of implementation(s) during
beta test prior to formal release based on user feedback - not coder
feedback.
7) discarding old features just because they are old doesn't even enter
into the equation - if the old feature provides adequate and widely
accepted user function, then it's priority for deletion and/or
replacement or change should be THE lowest possible, until it's
implementation is totally outstripped by current technology.
8) ALWAYS be ready to re-introduce a previous user interface
implementation based on user acceptance (or lack thereof) by maintaining
modular/transportable code, and maintain/archive historical state of
each release configuration. Fit required new under the hood code into
the previous user presentation - add, but do not delete user options in
doing so.
9) consolidate and streamline interfaces by smartly combining dialog
and/or input presentations without deleting user choice unless those
choices/options become completely outstripped by current technology.
10) consider the broadest base of abilities, users, and equipment
possible - for all platforms and users - when making interface changes.
What is a "move forward" for one may actually be a closed door for
another. No coder should make any change based on personal preference
alone. Consider and code to the worst case user scenario(s) - not coder
preference.
That a REALLY short treatise on how I've done it...and a fair start for
anyone else.
--
- Rufus
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
