Author Topic: Implement features that are known to be loved in other programs, on your own (Read 21315 times)

urlwolf · « **on:** August 15, 2011, 05:07 PM »

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 · « **Reply #1 on:** August 15, 2011, 05:27 PM »

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://businessofsof...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 · « **Reply #2 on:** August 15, 2011, 05:38 PM »

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 · « **Reply #3 on:** August 16, 2011, 11:36 AM »

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)

Because it takes time and effort

1- Live search. That is, you get hits as you type, with context.

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.

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.

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.

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.

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.

Apart from #6, I'd say I have some decent reasons why

skwire · « **Reply #4 on:** August 16, 2011, 12:12 PM »

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.

superboyac · « **Reply #5 on:** August 16, 2011, 02:37 PM »

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.
-skwire (August 16, 2011, 12:12 PM)

That's me! Recently, I wanted to understand this better, so I explored how people program in Visual Studio and RAd studio, and I can understand better what the developers have to deal with. It truly is a headache to add buttons and menu things that work just right, especially when it's not a simple on/off feature. A simple feature request can be a nightmare to implement, and I saw that to make it really pretty or elegant, or to remove some responsiveness issues sometimes means that you have to redo a lot of things from scratch. Especially when a lot of the components have come in from premade controls and stuff.

So I have a better and more sympathetic understanding now, thankfully. Hopefully, I'm not behaving as intolerantly as before with my feature requests!

wraith808 · « **Reply #6 on:** August 16, 2011, 03:45 PM »

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.
-skwire (August 16, 2011, 12:12 PM)

Amen. I need to print this out and post it LOL

skwire · « **Reply #7 on:** August 16, 2011, 03:51 PM »

You know...it's not always a matter of GUI controls or elegance. Sometimes, a user will suggest an idea, method or some functionality that, to the human brain, is done without a second thought. However, translating said idea to code is futile. I've sometimes thought to myself, "Humans are subjective, code is not."

I hope that made some sense...

mouser · « **Reply #8 on:** August 16, 2011, 03:53 PM »

Before you print that out and post it on your wall.. I think it misses the most important part of the equation.

My experience has been that it's rarely the time-to-implement that kills you.. It's the maintenance over time and added complexity and potential for unforseen interactions that does it.

It's often very easy to add a small feature request, but over time they do build up and tend to make the code harder to maintain and debug, and that's where you really get into trouble mentally.

Having said that, it's hard to resist adding features that make people happy

superboyac · « **Reply #9 on:** August 16, 2011, 04:19 PM »

You know...it's not always a matter of GUI controls or elegance. Sometimes, a user will suggest an idea, method or some functionality that, to the human brain, is done without a second thought. However, translating said idea to code is futile. I've sometimes thought to myself, "Humans are subjective, code is not."

I hope that made some sense...
-skwire (August 16, 2011, 03:51 PM)

Yeah, I agree with that. i keep wanting to define everything in life with precision, but it can't be done, and to try after a certain point is just an exercise in frustration.

Stoic Joker · « **Reply #10 on:** August 16, 2011, 07:49 PM »

Sometimes, a user will suggest an idea, method or some functionality that, to the human brain, is done without a second thought. However, translating said idea to code is futile. I've sometimes thought to myself, "Humans are subjective, code is not."
-skwire (August 16, 2011, 03:51 PM)

If I dare to think of the number of times I've had that conversation at the office I'll wake up screaming for a week.

wraith808 · « **Reply #11 on:** August 16, 2011, 10:48 PM »

My experience has been that it's rarely the time-to-implement that kills you.. It's the maintenance over time and added complexity and potential for unforseen interactions that does it.
-mouser (August 16, 2011, 03:53 PM)

My experience has been the opposite. I meant print it out because he puts what I've experienced more succinctly than I ever could. Though maintenance is a consideration, except in extreme cases, I haven't seen it be the primary consideration.

urlwolf · « **Reply #12 on:** August 17, 2011, 02:42 AM »

Hmm, so how about packaging that functionality in components that others can use, and sell the component?
Things like .net, seem to have everything under the sun, how come they don't have say smooth scroll text component or highlight all matches? Looks like cocoa does give you those already wrapped up for use...

I totally understand the complexity of some of these features. Some other, like breadcrumbs, are trivial, though.

vlastimil · « **Reply #13 on:** August 17, 2011, 02:59 AM »

I totally understand the complexity of some of these features. Some other, like breadcrumbs, are trivial, though.
-urlwolf (August 17, 2011, 02:42 AM)

Even a simple button is pretty hard to implement if you have to do it on your own. Processing mouse event (what if I click and hold and move the mouse somewhere else?), keyboard events (what if I press Space and then Tab), drawing the button using appropriate visual theme in the right resolution, possibly with customizations...

If the new feature cannot be accomplished using a standardized component, the amount of additional work increases significantly. Even in environments, where there is a lot of relatively easily integrable custom components, the component quality tends to be low (everyone just scratches their own itch).

Breadcrumbs in Vista/Win 7 file windows are implemented using a heavily customized toolbar intertwined with edit boxes. It is very hard to duplicate.

iphigenie · « **Reply #14 on:** August 17, 2011, 04:05 AM »

everybody think that breadcrumbs are simple - that is until you try to create a consistent breadcrumb trail that also can work as useful navigation with a behaviour that seems logical to most people. Ha!

justice · « **Reply #15 on:** August 17, 2011, 04:28 AM »

Should the OS not implement smooth scroll instead of the application? Perhaps it's not up to the app dev to provide functionality that's the OS'es to fix.

Same goes for shortcuts.

anandcoral · « **Reply #16 on:** August 17, 2011, 08:32 AM »

Allow me to put my view and notes from experience here.

@urlwolf has made a simple query "Why a programmer can not put feature X in his app A, which exist in app B made by another programmer on another platform/os/hardware etc."

From the time of DOS I could not reply to this simple question to any of my users satisfaction without being called arrogant. But now I have taken help from GOD's creation and have the answer for it.

User will ask "Why can't Notepad show bold and italics in same line as seen in Word, though both are editor and made by same company ?" The answer is "It is created that way to solve intended purpose".

GOD created hand and legs differently for different purpose. Same way notepad and word are created differently for different purpose. Notepad can not show bold/italics but Word can not load faster. If my little finger is smaller than middle one; it is intendend to be like that. At least we can rest assure that GOD did not have the resource and time problem of us programmer. HE could very easily made all figure same length and also could have added wings to our back.

My earlier Boss (fifteen years or so ago) requested me to make the invoice entry look like the actual printed invoice, on screen; as he has seen at his friends publishing house. He was referring to Ventura Publisher (PageMaker was another one), only problem was that he was expecting me to make it in his 8 bit green colour CRT in dBaseII, on which the inventory app I have made.

All these does not mean that we ignore users request. They are our existence. The technology and money was there but Nokia did not make a touch screen phone till Apple did it. Now I am a happy user of Nokia 5230 which is 1/4 of the price of iPhone and does all "what I need".

We have to listen to users and solve keeping in mind the time and money factor.

In one of my implementation, I installed IE4 at a clients site as the website I made did not work correctly in Netscape, and the client paid me for it. He wanted it to work.

So to put it happily to the demanding user, "Yes it can be done, but will take X time and Y money", but you must forsee the solution, as some users do pay for what they want.

BTW, I did made the invoice to show in graphics mode using dBaseII and GWbasic, though only preview and not the input. If any one used WordPerfect will know, it had similar feature for editing the document in text mode and previewing it graphics mode, in DOS.

Regards,

Anand

skwire · « **Reply #17 on:** August 17, 2011, 01:59 PM »

I totally understand the complexity of some of these features. Some other, like breadcrumbs, are trivial, though.
-urlwolf (August 17, 2011, 02:42 AM)

See? This is exactly what I'm talking about. How are you certain this is trivial? Are you a developer that has written some "breadcrumb code" into your own app? Most breadcrumb implementations I've seen seem to manipulate a standard ToolbarWindow32 class control. Manipulating those controls smoothly in real-time can be a right pain in the arse.

rgdot · « **Reply #18 on:** August 17, 2011, 02:11 PM »

Having read all this I have some demands for NANY 2012

Just kidding

app103 · « **Reply #19 on:** August 17, 2011, 03:37 PM »

I totally understand the complexity of some of these features. Some other, like breadcrumbs, are trivial, though.
-urlwolf (August 17, 2011, 02:42 AM)

Maybe it is trivial...maybe it is not. I can't tell you because I don't even know what you are talking about, which is another reason why some features do not exist in some apps.

skwire · « **Reply #20 on:** August 17, 2011, 03:49 PM »

Here's a good example (with screenshot): http://www.minimalis...ExplorerBreadcrumbs/

...and a Wikipedia entry: http://en.wikipedia....umb_%28navigation%29

app103 · « **Reply #21 on:** August 17, 2011, 04:22 PM »

Here's a good example (with screenshot): http://www.minimalis...ExplorerBreadcrumbs/

...and a Wikipedia entry: http://en.wikipedia....umb_%28navigation%29
-skwire (August 17, 2011, 03:49 PM)

Thanks!

Nope, probably not something I'd stick in one of my apps.

skwire · « **Reply #22 on:** August 17, 2011, 04:41 PM »

Well, they have absolutely have their uses in apps like file managers. I love the functionality that breadcrumb functionality brings. However, I know for a fact that it's not as trivial to implement as urlwolf says. It certainly isn't as easy as putting:

[Select]

Breadcrumbs = True

...and you're done.

urlwolf · « **Reply #23 on:** August 17, 2011, 04:59 PM »

I totally understand the complexity of some of these features. Some other, like breadcrumbs, are trivial, though.
-urlwolf (August 17, 2011, 02:42 AM)

See? This is exactly what I'm talking about. How are you certain this is trivial? Are you a developer that has written some "breadcrumb code" into your own app? Most breadcrumb implementations I've seen seem to manipulate a standard ToolbarWindow32 class control. Manipulating those controls smoothly in real-time can be a right pain in the arse.
-skwire (August 17, 2011, 01:59 PM)

I know nothing about win GUI programming. In fact, I do almost no GUI programing at all

I cannot tell if that's hard or not, other than by stretching intuition. In GTK, thunar does it using buttons, a button per folder in the path. It never turns into a textbox when clicked, though. I think nautilus does something similar.

When you see hardware innovation, you can count that there's a patent preventing others from copying it. Only logitech mice have that free spinning wheel, for example. But in the case of GUIs, it must be just a matter of effort to replicate things. I don't think if you make a component that highlights all search occurrences someone will come after you (I might be wrong; I'm using an EU-centric view where software patents are not so pervasive). Independently of how hard it is, I'm still surprised that softwave dev. is not more 'darwinian'. It takes a long time for innovations to reach all competitors. Opera 5 had tabs, at least 2-3 years before any other browser copied it. Was it that difficult to realize this was a good idea? Or was it so hard that they started copying immediately, but took them that long a time?

worstje · « **Reply #24 on:** August 17, 2011, 07:11 PM »

Opera suffered from bad marketing and a bad approach to selling it. The fact the free version had builtin ads for most of its life meant people simply didn't try it; those were the worst of the worst days when adblockers were in their infancy, regularly windowbombed the crap out of your pc so that it crashed, and so forth. The fact it had builtin advertising simply meant people were like 'no damn way am I adding more ads to my browsing experience!' Add to that that they never had the free advertising of simply being a popular opensource package, and they were always the minor lone wolf fighting Internet Explorer after the demise of Netscape (ok, there was Seamonkey, but that sucked donkey balls). Eventually, Mozilla got its act together and released Firefox. Opera had its chance, but to be fair: there were no successful business models for free browser software. Internet Explorer ruined that market, and there was no Google to play sugar-contract-daddy either.

Software-wise, it is very difficult to add good features, especially given that users tend to request visual things. Windows in particular is a crazy layer of cogwheels that work together to make the interface work. To provide a seamless experience, you need to support Windows Classic (with custom colours!), Windows Themes (visual styles, XP style), and Windows Aero. Doing that consistently on W7 is a huge headache on its own, then add support for older versions like XP. (Or start out for XP, go to W7.. my point remains similar.) Then throw in stuff like DPI, multi monitor support and perhaps even an inhouse style/configuration your application has to conform to, and you've got a huge feature matrix of hell already. Some applications are like 'hey, let's recreate all controls in our own custom theme'... and then you end up with a really crappy experience as a user. This is one of the reasons I dislike WPF - recreates all standard Windows controls, and I plain notice the little differences between the real win32 control and the WPF faked varieties. It makes it easier to make special custom controls, but it just as easily makes it possible to design those things so that the feature matrix tests want to cry. Ask cranioscopical - it took me a fair number of builds/versions just to get DPI handling right in JottiQ. Or JoTo for the partially unsolved issue with his High Contrast themes. JottiQ is one big chain of bugfixes/workarounds/etc for merely visual issues, and that really is a hell most easily avoided by sticking to the standard controls without fancy colours, images and the sort. (And then your application looks boring, making for crap screenshots and no downloads.

)