ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

Implement features that are known to be loved in other programs, on your own

(1/7) > >>

urlwolf:
Something that puzzles me is why programmer do not copy each other more often.
Implement features that are known to be loved in other programs, on your own. Why not?
For example:

1- Live search. That is, you get hits as you type, with context. A good example is cintanotes. When I see other programs implementing search as if it was 1990, I cringe. There's no reason inferior search results display is inflicted on us by mostly all other programs.

2- highlight all matches in search. All browsers do this well. Many text editors (!) don't. Not even word did it before word 2010

3- Have redefinable shortcuts. For all your functions. Very few programs do this consistently.

4- breadcrumbs in file managers. Still some don't have it.

5- rapid entry of tasks, by parsing some simple natural language instead of having to go through a long form. Example: google calendar, MLO rapid task entry

6- Smooth scroll. This is a big one. Really. Get out of browserland, and all other tools scroll like they were running in BASIC on a ZX spectrum. Even text editors. We have incredible GPUs, but your text must jump around the screen. Macs are superior here, scroll is smooth by default in all apps in cocoa.

In this day an age, I do not understand why good ideas do not spread faster. It's not that there are copyright issues. In case of breadcrumbs and XYplorer, DonL said he was too proud to copy this feature. While it may sound noble, is this justifiable? ignoring clearly superior design in the name of... what? honor? lazyness? innovation -my sucky feature may be better if I tweak it long enough-?

vlastimil:
I guess, the usual reason is limited resources.

Implementing feature X in its primitive incarnation costs N days. Implementing it intelligently costs 10*N. No one can do this for all the features in their software. The problem could be that we do not pick the right ones to implement properly.

Just yesterday, I watched this video http://businessofsoftware.org/video_09_gmoore.aspx , where Geoffrey Moore talks about innovation and how people should focus on and throw unreasonable amount of resources on their core features, but be very efficient when implementing all the rest.

superboyac:
100% agree.  I always have to be sensitive to developers when I make my strongly opinionated nitpicks about these "little" things.  But these little things really make or break a program for me.

The issue at hand is this: programmers don't relate very well to end users.  Programmers want maximum flexibility and power regardless of the amount of effort it takes.  That usually means command line.  End users hate command line stuff, so they want buttons and kiddie things like that.  So they ask for a button, the developer responds by saying "it can already do that, just type '/echo $%button-that_you_want?><321'" and is going to be annoyed by any follow up questions regarding the issue.  So that minor issue will be ignored, and the developer will proceed to program in a whole host of additional features that will only be accessed through command line code.

And I will also say this, even out of ignorance since I'm not really a programmer.  Discalimer!!!  This is not intended for any real people who might read this; this is purely FICTIONAL!!!!

OK, a lot of fictitious programmers have no desire to put in the work for stupid little things that just make the program better.  And part of the reason why is because polisihing and fine-tuning things is really really really hard.  What is that saying about 90% of the work does the last 10% or whatever it is.??  Anyway, developers make these great programs but stop before they really fine tune and pretty things up.  The video freeware tools are a perfect example of this.  Just one command line thing after another, and eventually someone makes a gui (that just calls a command window) that makes it a tad easier.  And I've tried my hand at programming a couple of times, and the gui stuff is very hard and tedious, that's why a lot of developers don't want to focus on it.  It's a lot of effort for seemingly minimal reward if you're in the mindset that you can spend the same amount of time programming in additional functionality.  to make a nice icon from scratch is boring and not worth it to them.  Neither is it worth figuring how to make a drop-down or some dialog that covers the options in a particular feature in an elegant, graphical way.  They don't care that much.

So then this philosophical battle emerges about what is good enough?  Programmers will argue that command line or just a tad more than that is all people need.  Guys like me will argue that the gui really is tremendously important, and we don't want to spend our time learning commands, no matter how easy the commands are.  Give us a button!!!

Some programmers that I feel have an excellent balance and elegance in their programs:
mouser (very good with balancing tons of features while still keeping the main GUI elegant)
the Editpad guy
bluebeam people
Directory Opus (yes)
Xyplorer
Spacemonger (brilliant)
skwire (amazing customer service speed also)
The Zentimo/USBSR people
Light Alloy

There's more...I didn't mean to leave anyone here off whose software I use and love.

f0dder:
Something that puzzles me is why programmer do not copy each other more often.
Implement features that are known to be loved in other programs, on your own. Why not?-urlwolf (August 15, 2011, 05:07 PM)
--- End quote ---
Because it takes time and effort :)

1- Live search. That is, you get hits as you type, with context.
--- End quote ---
Depending on the GUI toolkit you use, it can be somewhat bothersome to add this kind of live search. It's definitely no fun for raw win32 API coding :). And depending on what you're searching, it might be non-trivial to implement in an efficient way.

2- highlight all matches in search.
--- End quote ---
Could be a fair amount if the text control you use don't have explicit support for this feature.

3- Have redefinable shortcuts. For all your functions. Very few programs do this consistently.
--- End quote ---
Which is a shame. It's something you need to plan in before you start programming, as it's hell to do as an afterthought.

5- rapid entry of tasks, by parsing some simple natural language instead of having to go through a long form.
--- End quote ---
This can easily become a pretty complex task to implement - especially for regular developers in that haven't been dealing with natural language stuff. Google has the advantage of having a lot of people on their payroll :)

6- Smooth scroll. This is a big one. Really. Get out of browserland, and all other tools scroll like they were running in BASIC on a ZX spectrum.
--- End quote ---
I personally hate smooth scroll - at least pretty much all implementations I've seen. It's slower to get from position A to B, and often can't be stopped once you've started it (ie., spinning my mousewheel to scroll, I expect being able to contra-spin it to stop when I'm where I want to be - this tends not to work with smooth scrolling enabled).

In this day an age, I do not understand why good ideas do not spread faster.
--- End quote ---
Apart from #6, I'd say I have some decent reasons why :P

skwire:
I concur with f0dder's comments.  What it boils down to for me is ROI (Return On Investment):


* Is the requested feature worth the time it takes for me to implement it?
This includes trying to forecast how many other users would use such a feature.  That first question leads to the second question I ask myself:


* How easily can I implement such a request within the limitations of the GUI toolkit/controls I am working with?
This is something that non-programmer folks NEVER consider.  They see it done in one application and think it can be slapped into any other application in under ten seconds.  There have been instances where I would very much like to add a given feature but cannot due to such limitations.

What I've found over the years is that most non-programmer folks have zero idea how easy or hard an idea is to implement.  In fact, there have been lots of times where I have had requests from non-programmer types that they think is super easy (in their head) and, in reality, would be nigh impossible to do programmatically.

Navigation

[0] Message Index

[#] Next page

Go to full version