
Dangling by a Trivial Feature - nickmain
http://prog21.dadgum.com/160.html
======
fatbird
Any implementation must accept that you will lose users this way. You can't
implement every 'trivial' feature possible in order to avoid shedding users;
implementing one way precludes a different way that also sheds users. Overall,
you try to maximize the number of users that you don't shed, but that's it.
And in fact, you're frequently better off shedding users willy-nilly,
iteratively finding what the core features are that build a userbase, and
forgetting about all the rest.

This post is a prescription for paralytic featur-itis.

~~~
wvenable
I think part of the reason why developers that "dogfood" their own product is
so important to some people. If you use your own product, you tend to find
these sorts of important minor issues faster. I think, as developers, we've
all been guilty about missing obvious and simple areas for improvement because
we don't use the product, like users do, every day.

~~~
jzwinck
Or we have worked places where our bug reports are taken at low priority
compared to real customers'. Real customers often don't bother reporting
simple bugs, either assuming they will be fixed anyway or judging their value
(to one user) as too small. So fit and finish suffer, because developers who
do care are systematically ignored.

------
jthurman
As someone who sells software online, the most horrifying thing about this
scenario is that the user is very unlikely to ever tell me why they moved on,
and so I'm terrifyingly unlikely to ever know that this trivial feature is
missing.

This literally keeps me awake at night.

Statistic: it takes roughly 200 non-converting free trial downloads of my
software to get one data point of feedback telling me why they decided not to
buy.

~~~
Jare
This is why metrics and analytics have become superstars lately. Why hope for
your users to tell you, when the software can do it by itself?

Following the article's use case, the software could transmit the last dozen
or so commands or actions performed by the user. In a simplistic scenario, how
would you interpret it if 40% of your user's last commands are "Save"?
Success, surely! How about "Undo"?

The art and magic, of course, are in figuring out valuable yet inexpensive
metrics for your app, capturing that data when you have thousands or millions
of users, and interpreting the meaning.

~~~
ricardobeat
On the other hand, who wants their drawing software to track their every
movement?

~~~
krickle
This is hugely important. Any analytics had better be opt-in from a very
visible and honest request dialog. Otherwise, quite frankly, it's unethical.

~~~
josephlord
How do you feel about properly anonymous opt out logging?

My feeling is that anything personal including user content and searches
should be opt-in but opt out is ok for monitoring feature usage that can't be
linked to an individual. Obviously online/web apps reveal at least this
anyway. Does context web/mobile app/PC app make a difference?

~~~
krickle
My perspective is that you are using that person's processor time, so it's
okay to have anonymous opt-out if they know what is happening, otherwise I
don't think it's appropriate.

------
kemayo
The tricky part is that what some users think of as a must-have trivial-
feature, others won't care about at all. Thus getting every trivial-feature
for every user becomes a herculean task. (The standard "each user only needs
10% of a program's features... but they all need a /different/ 10%".)

For instance: I don't care about seeing my current cursor coordinates when
using an image editor. I probably have some other must-have tiny feature that
the author here wouldn't even notice.

~~~
wtallis
The author was looking for a vector illustration app, not a photo editor.
Vector graphics apps are often used to create diagrams and other semi-
technical drawings that require some CAD-like features, the simplest of which
is a usable coordinate system.

------
ivionday
I think something gets lost when we call this kind of shortcoming a missing
feature... A missing feature is too easy to dismiss since we can mention all
these scary words like "paralytic featur-itis." The fix here involves no new
dialogs, no additional learning curve, nothing fancy whatsoever. It's just a
case of absent-minded application design, and the point stands that it makes a
tremendous difference in the end product.

~~~
marshray
Another possibility is that the developers implemented it and the UI
designers/tech writers insisted that it be eliminated because it would
"confuse the users".

~~~
woah
It sounds like somebody could complain equally about it working the other way.
I don't think this guy's opinion is really a valid metric here.

------
dreamdu5t
This is why we should be using small, focused, interoperable modules instead
of large monolithic frameworks and applications that try to do everything.

A plugin architecture format shared by applications would be invaluable and
solve this problem.

~~~
saidajigumi
Folks have been musing along these lines for decades. There have been a few
attempts. To date, they've almost all failed. The problem domain here is a
__lot __more complex than anything we'd normally call a "plugin architecture".
IMO, the problem is that this sort of interoperability pretty much requires
the power of a full-on programming environment. If it's even possible, I think
it also requires an architectural organization that no one's yet divined.

The notable successes tend to be domain-specific and manifest as end-user
programming environments. The spreadsheet might be considered a weak example
of this. It has a clear user model that allows for powerful extensibility, but
doesn't really facilitate "interoperability" in any meaningful way -- each
spreadsheet tends to be a one-off.

The Max/MSP (and Pure Data/Pd) environments for audio/visual signal and event
processing are perhaps more successful in that they allow the simultaneous
construction of UI and logic in a visual programming environment. A program
(aka "patch") can be built as a reusable sub-program that manifests the same
kind of interface as the primitive (native-code) modules. But again, this is
another narrow domain application with a specific visual-semantic model which
works well for that domain. That contrasts to the OP's problem of adding
arbitrary UI to a software whose main domain has nothing inherently to do with
either the added UI or even to programming.

I'd also say that the venerable programmable programmer's editors, Emacs and
Vim, form another category of end-user programming environment with loose
interoperable modules. These are certainly subject to a fairly high degree of
extensibility within their domains. But these are saddled by frustrating UI
constraints and architectural models inherited from their now ancient origins.
Interoperability between "modules", such as it is, is largely ad-hoc and far
from guaranteed.

Each of these successes can teach us something about what works for these kind
of programmable-framework environments. But to achieve The One Architecture To
Rule Them All goes beyond simply having the tools of design, architecture,
language, and environment. It must also become a computing platform, where by
"platform" I mean an ecosystem that's large enough to have the _social_
synergies that make the above examples and other conventional software
platforms successful.

~~~
winter_blue
> To date, they've almost all failed.

Eclipse is an example of an immensely successful plug-in architecture-based
software.

It's amazing how well plug-in ecosystem in Eclipse operates. For instance, I
could install the PyDev plug-in and have an intelligent Python editor -- but
at the same time the EGit plug-in provides seamless git integration that works
with any language!

How all these plug-ins come together and play nice with each other to create a
cohesive and powerful IDE is impressive!

------
guard-of-terra
That's why you need settings in your tools.

The tool should work efficiently without you ever looking at the settings, but
if you need it you should be able to change anything you like.

Not sure it applies to consumer interfaces. Ideally it shouldn't. But for
tools that you use to do day-to-day work, absolutely.

~~~
bbq
Settings are for microwaves. Computer-based tools should be reprogrammable.
Still, the tool should be easy to configure for the 80% case.

~~~
mcpherrinm
Settings on a microwave are, I think, a terrible example. Most microwaves I've
used are horribly over-encumbered.

I expect two dials on any microwave I use: Time, Power. Maybe a control to set
the time, if it has a clock.

I don't disagree with your general point about tools being able to be
reprogrammed, though. One of the reasons I loved Autocad as a tool is the Lisp
interpreter that allows you to script and extend it. I think that's a perfect
example of a professional, mainstream tool with a good API that non-
programmers find useful (if only to run scripts they find).

~~~
ansgri
Autocad has a very interesting GUI concept, not in that it's programmable (VBA
existed in CorelDraw for years), in its dialogue mode: you click a circle, and
it asks you of a center; you either click or type coordinates. Sadly, this
mode is rare in non-CAD systems.

~~~
Gravityloss
Solidworks used to work like that too, it's a delight to just start a line and
keep on typing distance deltas in numbers and see stuff emerging without a
single mouse movement.

------
tikhonj
This is why I love Emacs--if there's a trivial feature missing, adding it
myself is almost always _easier_ than even thinking about installing something
else. 90% of the time, somebody else has a code snippet on StackOverflow or
Emacs Wiki. 9% of the time, I can code it up myself with essentially no hassle
--Emacs is self-documenting and makes developing Emacs _in_ Emacs a pleasure.
The remaining 1% of problems I usually just ignore: no program is going to be
perfect, and Emacs is already more than close enough.

------
b1daly
What boggles my mind is when obvious usability problems persist over multiple
versions of an application.

(A quick example: Apple's spreadsheet app Numbers has a behavior where the
handle for moving a chart around on the workspace disappears if the chart is
moved all the way to the left. It kind of docks the window, requiring an
annoying work around to free it. There's no way anyone who uses it would not
encounter this, but it's been that way for many years)

The problem space of user facing features is overall quite complex. A
developer can neither understand the beginning user's experience, nor the
heavy user (they usually don't have the time to use their own application as a
worker would, IDEs being an exception.)

Just blindly adding features because a user requested isn't a solution for
obvious reasons. I think a combination of user feedback, usability testing,
quantitative analysis, along with creative problem solving by developers and
product people is needed. Not to mention the nitpicky reality of there being
an actual business case need for the feature.

------
mikecane
It's very simple. In any environment, the person who asks, "Why would a user
want to do that?" is the one who should be fired first.

~~~
Bill_Dimm
I disagree. Understanding how users use your software and what they are trying
to accomplish with it is important, and it is not always obvious _why_ a user
is asking for a particular feature without asking. Furthermore, when you learn
what the user is trying to accomplish with the feature they are asking for you
may realize that there is a better way of providing that functionality rather
than the specific approach the user requested.

~~~
furyofantares
I think the two of you are mostly in agreement. I believe mikecane is talking
about someone that believes their mental model of users' needs, desires, and
expectations is complete, and is using the question as a way to shut down a
feature, with the implication being "if the reason someone might want X is not
immediately obvious to me, it must not exist."

I don't think he was talking about someone that acknowledges that their
understanding of users is incomplete and wants to learn more.

~~~
mikecane
Yes. As an example, Jobs putting actual typefaces into the original Mac.
Anyone used to the existing computing paradigm back then would have asked,
"Why would a user want that?" Another infamous example is the marketeers at
CompuServe thinking the CB Simulator was a bad idea -- and today we have
something like it, called Twitter.

~~~
temp8675309
Why is Twitter a good idea? It's clearly an idea that's achieved traction with
a userbase, but what is it about Twitter that makes it a "good" idea?

~~~
mikecane
People like to chat with other people in real time. CompuServe's CB Simulator
was a huge money draw for them (back then you paid per minute of connect-
time).

------
greggman
I'd argue this is why many open source project who's target audience is not
developers are not nearly as good as their commercial counterparts.

When the software is made for artists there's a very different dynamic at work
then when a a similar piece of software is created by engineers just to
scratch an itch .

------
mahesh_rm
This is how I feel every single time I happen to use GIMP while working on
rails in fedora, and don't want to reboot into windows and fire up photoshop
just to change a transparency. I wonder why open source has often to be
synonymy of poor GUI ergonomy.

~~~
ilaksh
I think its a combination of things.

For starters, its built on a volunteer basis, so there is no monetary reward
for making it easier to use.

Also, some of the developers are probably actually unaware of the main
concepts in UX design and even don't want the software to be user friendly
because to them that is synonymous with 'dumbing-down' the system for
beginners.

><http://developer.gimp.org/gimpcon/2006/index.html>

GIMP targets experienced users. If we acknowledge that GIMP is not (primarily)
for beginners, we cut off a lot of problems such as “do we need to support
that,” etc. Peter noted that a “GIMP Light” would not just have some options
cut off from the menus: it would have a completely different user interface,
even if it would use the same code under the hood.

Some developers work on GIMP to promote the Free Software movement and would
probably not contribute if GIMP was not free. Others think that GIMP should
provide fun for its developers, although our user base has grown a bit large
for just doing fun experiments. We have to acknowledge that we address a user
base that may be more experienced in image manipulation than we are, so the
developers are partially out of the target group.

Before converging towards a definition of the GIMP target groups and GIMP
vision, there were several discussions involving examples and use cases,
whether GIMP should be the best image manipulation program in the universe
(best for who?), whether those working on icons and those working on photos
have the same needs (number of images open, relative sizes), whether people
need to switch frequently between GIMP and other applications (browser or
editor for web work), whether we will support painting with shapes and natural
media, etc.

Eventually, a GIMP vision emerged...

What GIMP is:

GIMP is Free Software

GIMP is a high-end photo manipulation application, and supports creating
original art from images;

GIMP is a high-end application for producing icons, graphical elements of web
pages, and art for user interface elements;

GIMP is a platform for programming cutting edge image processing algorithms,
by scientists and artists;

GIMP is user-configurable to automate repetitive tasks;

GIMP is easily user-extendable, by easy installation of plug-ins.

What GIMP is not:

GIMP is not MS Paint or Adobe Photoshop

TODO

Make it easier to perform repetitive tasks (macro recording)

Provide a UI with a low barrier to entry

GIMP should be easily extensible by the average user: one click-installation
of plug-ins

Well, "a UI with a low barrier to entry" was on that TODO list at least. If
they had hundreds of thousands of dollars lying around, probably someone would
have been hired to focus on that one. But they have zero dollars and its not a
big enough priority for most of the developers to motivate the type of changes
required.

------
baddox
What if for every person that agrees with the author, there are 2 people that
will immediately dismiss the product if it _does_ show this extra information
in the status bar? I'm not saying that is likely, but it's certainly
conceivable. What _is_ likely is that more users will be discouraged or
overwhelmed as the number of onscreen data and configurable settings
increases.

------
readme
Chances are OP downloaded an open source svg program. I'd have to guess
inkscape. At this point, the right move would have been to either post a
feature request on launchpad or implement the functionality yourself.

If you don't want to get your hands dirty, pay for illustrator.

------
misleading_name
I think this is where customer testing comes in. Watch 10 or 100 customers try
to use you product, and observe the features they "reach for" but are not
there - and the ones that are there, but they never use.

------
javajosh
Your understanding of the domain changes considerably as you implement an
application in that domain, reducing your ability to approach the domain as a
beginner.

