Dangling by a Trivial Feature • Hacker News Board

Re: Dangling by a Trivial Feature

#21

Post by gdubs » Sun, Dec 23, 2012, 9:45 PM UTC

fatbird wrote: post #14

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…

Came here to say this. It pains me to think of great products not being released because they don't have the _perfect_ set of features. Until you get real-world feedback from users it's often hard to guess what those must-have features are, anyway.

Re: Dangling by a Trivial Feature

#22

Post by baddox » Sun, Dec 23, 2012, 9:52 PM UTC

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.

Re: Dangling by a Trivial Feature

#23

Post by siganakis » Sun, Dec 23, 2012, 10:03 PM UTC

dreamdu5t wrote: post #17

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.

But then you have the new problems of what plugins to include by default, how users discover plugins and how they are configured.

Plugins, while valuable for people willing to take the time to learn about your product's eco-system are unlikely to help users who are willing to spend only 5 minutes evaluating your product.

Re: Dangling by a Trivial Feature

#24

Post by DanBC » Sun, Dec 23, 2012, 10:04 PM UTC

guard-of-terra wrote: post #5

georgemcbay wrote: post #3

Earlier quoted context omitted.

It is also why your settings must be absolutely simple, logical and follow conventions of whatever platform you are on (if any). If I have to dig through 10 pages of arcane settings to find some "simple thing" like the one described in the OP's example feature, it might as well not exist (assuming the context that I'm a new user and not already committed to using this software), I've already moved on to the next cand…

I doubt there is a wide choice of professional tools in most areas. You have to choose between a few suboptimal fits, and that's where you start valuing flexibility.

And they're often closed source, so there's limited chance to add the features.

You might be able to ask users on some forum.

And maybe there's something on the website about feedback or feature request.

Having said all that how do you control the flood of "Why doesn't X do Y?" (when Y is in the menu, on the tool bar, on the splash tips of the day, in the tool tip, etc)

Re: Dangling by a Trivial Feature

#25

Post by guard-of-terra » Sun, Dec 23, 2012, 10:07 PM UTC

DanBC wrote: post #24

guard-of-terra wrote: post #5

Earlier quoted context omitted.

I doubt there is a wide choice of professional tools in most areas. You have to choose between a few suboptimal fits, and that's where you start valuing flexibility.

And they're often closed source, so there's limited chance to add the features. You might be able to ask users on some forum. And maybe there's something on the website about feedback or feature request. Having said all that how do you control the flood of "Why doesn't X do Y?" (when Y is in the menu, on the tool bar, on the splash tips of the day, in the tool tip, etc)

Theoretically it should be solved by making everything scriptable, but in practice this solution tends to only work for a small subset of users (who could benefit from customization).

We still have this road ahead.

Re: Dangling by a Trivial Feature

#26

Post by DanBC » Sun, Dec 23, 2012, 10:11 PM UTC

mikecane wrote: post #16

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.

Oh my!

CLUELESS_BOB PHB "Hey, can you do this for the project?"

CLUEFUL_ANN DEV "Well, I could do that, but the question I want to ask is 'Why the hell would anyone want that?'".

--

See also the confusing non-match between password echoing in gui or command line environments. Someone needs to ask "Why would a user want to do that?" and then get it done.

Re: Dangling by a Trivial Feature

#27

Post by MichaelGG » Sun, Dec 23, 2012, 10:14 PM UTC

dreamdu5t wrote: post #17

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 framework to specify all this stuff in the first place.

Re: Dangling by a Trivial Feature

#28

Post by saidajigumi » Sun, Dec 23, 2012, 10:16 PM UTC

dreamdu5t wrote: post #17

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.

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.

Re: Dangling by a Trivial Feature

#29

Post by Livven » Sun, Dec 23, 2012, 10:22 PM UTC

furyofantares wrote: post #20

Bill_Dimm wrote: post #18

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…

That's how I understood it too, and I completely agree with it.

Re: Dangling by a Trivial Feature

#30

Post by ivionday » Sun, Dec 23, 2012, 10:52 PM UTC

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.