Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 07, 2016, 10:27:49 AM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

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

J-Mac

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 2,913
    • View Profile
    • Donate to Member
I understand that features requested by users may not be simple to implement and/or maintain, but doggone it some of the relatively big-ticket apps ought to be including such features. I'm thinking of editors and PIMs/outliners that fall into the $80 to $150 price range. Some of those that I have are lacking most of the features that were mentioned in the original post, and even if it won't be easy this is the kind of feature that so-called "major upgrades" are supposed to include, at least IMO. Not just add a ribbon-look GUI. I've requested some similar features and had them refused, not because they aren't easy to implement but because the developer "doesn’t see what that does"!

Jim

wraith808

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 8,406
  • "In my dreams, I always do it right."
    • View Profile
    • Donate to Member
In the end, using a program is a contract between a developer and the user community.  Both have an investment in the product, and the developer has to have a certain amount of buy-in to implement features, because he has a great responsibility to his product in order to keep the vision and the direction.  If he doesn't see what the value of a feature is, and doesn't see what it will add to the life of the product/it doesn't fit his vision, then I don't think that's a failing of the developer necessarily- it's just a change in the direction of the product that he doesn't want to make.  Then it becomes the user's responsibility to either make a more compelling case with the help of the rest of the community, accept that this feature will not be in the product, or start to look into different products.

TL;DR - just because it's easy to implement, doesn't mean it's right for the product, IMO.

Armando

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 2,727
    • View Profile
    • Donate to Member
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.

Actually, in a way it all seems very Darwinian to me. Look around you : single-celled species, algae, sponges, etc., many insects and some animals like crabs and turtles, IIRC, which were already here hundreds of millions years ago. They're still unchanged, happily humming along and completely part of our ecosystem.  Why ? simply because, somehow, "something's enough" and they don't need to change, adapt. Some balance (users' requests / programmer's resources / complexity .... see Wraith's post) has been achieved.

Cultural changes/evolutions is also interesting to look at. Take some cultural/societal systems as basic and fundamental as women rights and democracy. We might see "equal rights of men and women" as a given, but... For women rights we had to wait for the 19th century for the beginning of it, and then it was a rather slow process... In the 21st century it's still not "implemented" everywhere. Same for democracy, but the process is even longer... Yes, sure, we're getting there.

Spoiler
[Disclaimer: not saying democracy is the light of the end of the tunnel etc., just using it as convenient example.]


So that said, isn't it quite understandable (and normal) to witness various "application/program species" coexist, and even in the same "historicotechnological" context?
« Last Edit: August 21, 2011, 11:03:07 PM by Armando, Reason: coined \"historicotechnological\". Cute, isn\'t it ? »

NinJA999

  • Supporting Member
  • Joined in 2008
  • **
  • Posts: 79
    • View Profile
    • Donate to Member
I'd like to chime into this discussion with a few notes.

First, I find that sometimes when asking questions like these, it helps to compare programming with something else.  Take architecture, for example.  Writing a program is similar to creating a building -- there are many things to take into account and the final product is used by many people.

It may seem simple to dismiss programming as super easy due to the availability of free IDEs and tools and the proliferation of software development communities.  However, it is important to recognize that there is a lot more below the surface than just tapping a few keys mindlessly.  This is why a comparison with architecture is valid.

Picture this: you stroll up to an architect and ask him, "Why don't you put all these great building features on every building you create?  I love porticos and pillars and balconies and bay windows; they work so well on all the famous buildings!  Why not implement them all?".

His response might be something like: "Well, there are several different considerations.  First, everything I design has to work with everything else towards load balancing and cooperation with various building codes, among other things.  I also have to consider aesthetics -- each of these things may work nicely on buildings you have seen, but if they do not fit into the building design, I shouldn't use them.  I wouldn't put colonial-style pillars on an art-deco apartment building!"

The same applies to software development.  Sure, the things you have mentioned are great features that work really well on the programs that you have mentioned.  But why should I put breadcrumbs into my mail merge application?  Do I need to put natural language processing in my text editor?  We also have certain requirements we must satisfy.  These vary: sometimes, money is an issue; other times, time is an issue; more often, framework limitations are the issue.  You ask why there aren't .NET libraries offering these features.  That's because some of these must be done in a certain way.  If I want to add search-highlighting, first I must change all of my textboxes to richtextboxes to support colored highlighting.  Then I must decide on the implementation of how to do the highlighting (which, within the limitations of the richtextbox which I am far too familiar with, means going through and highlighting everything one at a time, hoping you will be able to reverse the highlighting and salvage the original document).  Components can be great, but only if they can work within the limitations of their environment.

As for your saying that you understand some things are hard, but of course breadcrumbs are easy...again, imagine talking to the architect.

"I understand making pillars is hard.  But I know that it's super easy to create a fourth-floor balcony."

That would be considered an absurd statement to make -- who are we to tell an architect we know how to do his job better than he does?  We have no clue about the building's weight distribution or the building codes that he would have to consider.

Think about the comparison the next time you try to tell a programmer how extremely easy things are.

To address the idea of programmers always only being concerned about efficiency: sure, we like efficiency.  But *not all* of us hate GUIs.  When I'm working on my linux server, sure, I'm proud when I can accomplish five things with a few keystrokes.  On my Windows system, I'm happy to use friendly GUIs.   But it is completely absurd to have a programmer respond to "can you add a button to do this" with "just use the damn command line!".

We understand that users of our products like things to be simple.  Hence the term "user-friendly".  We try very hard to make things as easy and powerful as possible.  Sure, there might be the occasional cave-dwelling coder who hates people and tries to make things faster at the expense of a GUI.  That person typically gets moved away from the front-end of the program and towards internal code.

One of the most important things in software development is making software that regular people can use.  A lot of this comes from taking common elements ("affordances") from popular products.  We do try to add them to make it easier for the user.  We (or at least I) take pride in having created an application that is a joy to use, an application that people don't grumble about every time they open it.

However, as I said above, these elements do not always fit.  We also have to balance money, time, and other features.  If our constraints limit us to either adding customizable shortcuts or making our core functionality work, guess which we chose?  We try to get the core functionality out and usable; later, we can go back and spend some more time making it nicer and easier to use.

Basically, what I'm saying is: as a programmer, I'd love to be able to implement popular features all the time.  And I do so when I get the chance.  But there are several reasons why this cannot be done all the time, and it is a little unreasonable to say "I know this is easy -- why isn't it done?".  It's an attitude like that which generates the cave-dwelling coders who hate users.  And nobody wants that to happen!  Be nice to us, suggest features, and we will attempt to implement them in a somewhat timely manner.  We do, in fact, like users and usability!

Also, in case you think this is some bitter, angry rant: I meant for this to be a level-headed discussion.  I am not placing any blame, nor am I typing this out of any sense of anger or righteousness.  I know that it can be hard sometimes to divine emotional context from plain text.
« Last Edit: August 22, 2011, 12:46:23 AM by NinJA999 »

J-Mac

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 2,913
    • View Profile
    • Donate to Member
Ninja999:

I'm not sure that your comments address the original questions posted by Urlwolf.

First, Urlwolf's questions addressed existing software while your analogy appears to address new, as your building design sounded new instead of a refit. Plus your desired features sound like nice-to-have stuff. What about features that would tend to bring the program up to par with more current competitors' apps? I don’t know myself how difficult it is to add breadcrumb trails but they are a definite valid requirement, if not entirely necessary, for some programs such as file managers. Another is a good search capability in a data clipping and archiving program. If a developer doesn’t feel that's needed - not as a minor addition but maybe as part of a "major upgrade" then that developer will most likely see sales start to sag.

Anyway, I'm not talking "porticoes and bay windows"! I asked a developer of a program like I mentioned above - data clipping and archival - for some search improvements and was told that he felt if his program's search feature found articles relevant to the search then it is successful. (I was asking for highlighting improvements.) Things like that aren't bay windows, at least IMO. But hey - there are other programs that do closer to what I want. Just a shame that I have to start a search for a new program when the existing cost almost 3 figures.

Thank you.

Jim

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 36,408
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
NinJA999,

Your analogy to an Architect designing a building is a really interesting one.

Although there are many differences when talking about a piece of software, where many features can be disabled or set in options, I think many of the points you are making can be seen at work in some of the most elegant software applications -- where authors really do consider themselves like architects -- trying to keep everything consistent and elegant and striving to create something with an artistic vision.

wraith808

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 8,406
  • "In my dreams, I always do it right."
    • View Profile
    • Donate to Member
Although there are many differences when talking about a piece of software, where many features can be disabled or set in options, I think many of the points you are making can be seen at work in some of the most elegant software applications -- where authors really do consider themselves like architects -- trying to keep everything consistent and elegant and striving to create something with an artistic vision.

When designing a building, there are also several options that can be 'turned on and off' in a manner of speaking.  It's not as simple as flipping a switch, but it is relatively as easy as that in comparison, i.e. colors of paint, or tiling, or other such things.

I think that NinJA999 is right on with a lot of his analogies; though many software developers are just trying to get things done, I think that most that are in the field are trying to better themselves, and write software that shows this.  I've been architect on a few projects in a few locations (don't currently have the title at my current position, but I am doing the work of one, and hoping for a promotion soon), and when in that position in an enterprise, you have to take such things into account- at least if you want to maintain your position.  Because once all is said and done, whatever framework ("foundation") you've put in will limit what can be built on top of it.