Live data from Hacker News

Dangling by a Trivial Feature

prog21.dadgum.com

41–50 of 63 posts

Re: Dangling by a Trivial Feature

#41

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.

... we have that, it's called dynamic linking. Much more than that, and you're back at the start. In this case, the plugin would need to interop with the app to pickup internal UI states (dragging a selection rectangle, versus just moving an item) and interface with that coordinate system. I'm curious how you think you'd have "interoperable modules" that would provide such functionality, without creating a large fram…

> …without creating a large framework to specify all this stuff in the first place.

It is, in most cases, significantly more work to create a plugin architecture that could allow for some feature to be implemented than it would be to implement that feature statically — and most of that extra work is not shared.

Re: Dangling by a Trivial Feature

#42
post #37

Earlier quoted context omitted.

Do you have any current examples of consumer level microwaves with that simple interface? I've been looking for exactly that sort of simple microwave, but I haven't been able to find any in my brief searches on the internet or in the large mart style stores.

This Samsung model is the most popular one in Sweden currently: http://www.samsung.com/se/consumer/appliances-kitchen/microw... But when you look at the Samsung US range of microwaves: http://www.samsung.com/us/appliances/microwaves/all-products ...it becomes clear that (Samsung US belives) simplicity doesn't sell as well there...

Almost all the microwaves I see in Finland require that the user rotates the dial and off you go. With US microwaves I use the first 30s to scratch my head trying to figure out into witch category my food belongs to. But then again, the same happen with other devices as well: US products are full of settings and preconfigs.

Re: Dangling by a Trivial Feature

#43

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 p…

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".

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.

Re: Dangling by a Trivial Feature

#44
post #33

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 decide…

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…

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

Re: Dangling by a Trivial Feature

#45

Earlier quoted context omitted.

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 th…

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 th…

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.

Re: Dangling by a Trivial Feature

#46
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.

Re: Dangling by a Trivial Feature

#47
post #33

Earlier quoted context omitted.

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…

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

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.

Re: Dangling by a Trivial Feature

#48
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.

Re: Dangling by a Trivial Feature

#50

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.

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.

Post reply on HN