Upgrade Priorities

[knowschad]

With the recent full-sweep update of the visual aspect of the site, I have to ask TPTB how the webiste programming priorities are determined. This forum is chock full of requested enhancements. I recall one particular thread with several pages of enhancement requests for the maps alone, some of which TPTB even stated that they agreed and wanted to get them done. And yet, instead we get visual changes that the majority here (me excluded) seem to hate.

 

I totally understand that you can't constantly bend to the whims of your users, but many of these requests are very good ones and have been around for a long time. Why do they keep getting tossed aside in favor of changes that few of us really care about?

 

 

RSVP

[OpinioNate]

There is a simple explanation.

 

We employ web designers to design, programmers to program, and testers to test. Granted we need more of the latter, but you might be disappointed in the result if we asked our designers to make a geocaching map. It would be pretty as all get-out, but wouldn't do much in the way of mapping.

 

Bottom line is we never stop thinking of ways to make the site better, and as a result we have enough work to keep an army of people busy for years. At some point we have to say one thing is more important than another and just go with it. I understand our decisions won't always make sense from the outside looking in.

[knowschad]

There is a simple explanation.

 

We employ web designers to design, programmers to program, and testers to test. Granted we need more of the latter, but you might be disappointed in the result if we asked our designers to make a geocaching map. It would be pretty as all get-out, but wouldn't do much in the way of mapping.

 

Bottom line is we never stop thinking of ways to make the site better, and as a result we have enough work to keep an army of people busy for years. At some point we have to say one thing is more important than another and just go with it. I understand our decisions won't always make sense from the outside looking in.

I think you have plenty of the latter, LOL!! I guess you meant programmers when you said that.

 

 

Yeah, don't want the artists messing around with code, I guess, any more than vice-versa. But I'm talking

 

about changes that have been requested (and in at least one case, I believe it was you that stated that you also really wanted make the change that was requested) and we keep waiting, release after release, after release and instead of seeing the features or enhancements that we asked for, we see things that we never asked for and that benefit very few of us.

 

For example, I could care very little about what sort of GPS Castle Mischief uses, but if I do, I will email him and ask. A programmer's precious time was used to add that (to me) useless "feature" when instead, I could perhaps click on "Create Pocket Query" from a map where I had excluded multicaches and mysteries, and seen those already unchecked in the pocket query.

[+StarBrand]

Knowing the process well - I can understand that what looks like an uneeded visual update really is laying the necessary groundwork for some of those many requests.

 

Unfortunetly - it looks like the programmers did not only the programming but strayed into design work as well. I can recognize that as the programmer side of me is often the stronger personality.

 

I get faulted for very ugly but highly functional websites all the time.

[+GeePa]

We employ web designers to design, programmers to program, and testers to test.

 

I am not familiar with the typical practices of web development, but I did work for a while in development of desktop software. In this we had four roles. We had product managers to determine what were the features to add as well as their high level functional requirements (based on customer feedback and economic return), designers to design UI layout and end user experience details, programmers to code the changes and testers to test the changes. The one role that is missing in what you said was the folks who determine what exactly it is that should be done. I think the real question from the OP was how is this role managed within Groundspeak.

 

BTW, I really like the new look personally. I think everything is easier on the eyes so I have no beef with what was done.

[+StarBrand]

...

BTW, I really like the new look personally. I think everything is easier on the eyes so I have no beef with what was done.

Me too.

[knowschad]

I think the real question from the OP was how is this role managed within Groundspeak.

BTW, I really like the new look personally. I think everything is easier on the eyes so I have no beef with what was done.

Yes, and yes.

[OpinioNate]

We employ web designers to design, programmers to program, and testers to test.

<snip> We had product managers to determine what were the features to add as well as their high level functional requirements (based on customer feedback and economic return), designers to design UI layout and end user experience details, programmers to code the changes and testers to test the changes. The one role that is missing in what you said was the folks who determine what exactly it is that should be done. I think the real question from the OP was how is this role managed within Groundspeak.

 

Without getting into too much detail, this is essentially correct. The missing role is mine as Product Owner, a Scrum term that basically means I communicate the needs of the community to the executives who make the final decision as to what our priorities are. I try to be thorough but will freely admit I sometimes fail to interpret your priorities as the customer, and other times I'm simply overruled.

 

The GPS Device feature was mentioned as an example of a feature that is a "useless" orange compared to some other apple. Well that useless feature puts money in the bank which is used to keep the business afloat. It also serves as a good resource for people in the market for a new GPS by providing reviews by geocachers. Something else you couldn't know is that a new developer to the company built that feature and it served as a good introduction to our code. That same developer was not yet familiar enough with our code to build a PQ-from-map feature so it's unfair to say we robbed Peter to pay Paul in this case. There are many other intricacies involved in our decision-making to which the average users aren't privy.

 

Bottom line is it's in our best interest to give the people what they want. What's good for you is good for Groundspeak is good for you. I also happen to enjoy serving people so I have a personal interest in making you happy.

[+L0ne.R]

Without getting into too much detail, this is essentially correct. The missing role is mine as Product Owner, a Scrum term that basically means I communicate the needs of the community to the executives who make the final decision as to what our priorities are. I try to be thorough but will freely admit I sometimes fail to interpret your priorities as the customer, and other times I'm simply overruled.

 

The GPS Device feature was mentioned as an example of a feature that is a "useless" orange compared to some other apple. Well that useless feature puts money in the bank which is used to keep the business afloat. It also serves as a good resource for people in the market for a new GPS by providing reviews by geocachers. Something else you couldn't know is that a new developer to the company built that feature and it served as a good introduction to our code. That same developer was not yet familiar enough with our code to build a PQ-from-map feature so it's unfair to say we robbed Peter to pay Paul in this case. There are many other intricacies involved in our decision-making to which the average users aren't privy.

 

Bottom line is it's in our best interest to give the people what they want. What's good for you is good for Groundspeak is good for you. I also happen to enjoy serving people so I have a personal interest in making you happy.

 

This is great information. I appreciate knowing what's being considered and why it may or may not be implemented.

 

Some of the things I'm interested in are:

• Is Groundspeak considering a rating system? (tindling's Nov 5 2009 detailed outline was one of my favorite responses to the ratings implementation discussion)
  
• Is Groundspeak considering a way to use a polygon tool to select caches in an area via the 'map it' feature?
  
• Is Groundspeak considering a way to block all cache hides from a particular cacher?
  
• Is Groundspeak considering an option to hide find counts on our online logs?
  

Edited January 13, 2010 by Lone R

[+Zop]

 

Bottom line is it's in our best interest to give the people what they want. What's good for you is good for Groundspeak is good for you. I also happen to enjoy serving people so I have a personal interest in making you happy.

 

 

We would really like to believe this however to see a functional production site replaced with a buggy beta site with tons of visible front-end and not so visible back-end scripting errors leads us to disbelieve.

 

Perhaps in the future TPTB may consider thoroughly testing on a parallel test system before cut-over?

[knowschad]

We employ web designers to design, programmers to program, and testers to test.

<snip> We had product managers to determine what were the features to add as well as their high level functional requirements (based on customer feedback and economic return), designers to design UI layout and end user experience details, programmers to code the changes and testers to test the changes. The one role that is missing in what you said was the folks who determine what exactly it is that should be done. I think the real question from the OP was how is this role managed within Groundspeak.

 

Without getting into too much detail, this is essentially correct. The missing role is mine as Product Owner, a Scrum term that basically means I communicate the needs of the community to the executives who make the final decision as to what our priorities are. I try to be thorough but will freely admit I sometimes fail to interpret your priorities as the customer, and other times I'm simply overruled.

 

The GPS Device feature was mentioned as an example of a feature that is a "useless" orange compared to some other apple. Well that useless feature puts money in the bank which is used to keep the business afloat. It also serves as a good resource for people in the market for a new GPS by providing reviews by geocachers. Something else you couldn't know is that a new developer to the company built that feature and it served as a good introduction to our code. That same developer was not yet familiar enough with our code to build a PQ-from-map feature so it's unfair to say we robbed Peter to pay Paul in this case. There are many other intricacies involved in our decision-making to which the average users aren't privy.

Bottom line is it's in our best interest to give the people what they want. What's good for you is good for Groundspeak is good for you. I also happen to enjoy serving people so I have a personal interest in making you happy.

Thanks, Nate. That was a very helpful explaination of the thought process. I do understand the commercial needs, and only used the GPS Device feature as the first example that popped into my head of something that (as far as I know) the users did not request but received anyway.

[cezanne]

There is a simple explanation.

 

We employ web designers to design, programmers to program, and testers to test. Granted we need more of the latter, but you might be disappointed in the result if we asked our designers to make a geocaching map. It would be pretty as all get-out, but wouldn't do much in the way of mapping.

 

I agree with you as your last argument is regarded, but your explanation does not comment on the aspect how the priorities are split with respect to the areas web design and implementation work (coding work). You wrote at some other place that you like to make people/customers happy. From that point of view the question comes up to my mind whether or not it would make sense to employ more programmers and testers and less web designers. (Of course the actual decision is yours.) The old layout of the site made apparently more cachers happy (which you mention as one of your goals) than the new one. I cannot see any link between the implemented visual changes in the site and the intention to offer some parts of the site in other languages as well.

 

Cezanne

[+Frank Broughton]

I understand our decisions won't always make sense from the outside looking in.

 

But without the outside, you will have no inside to look out of. The decisions seem based on stopping things instead of creating excitement and awe. I do pray I am dead wrong on that. I guess stopping things is progress too.

[jholly]

I understand our decisions won't always make sense from the outside looking in.

 

But without the outside, you will have no inside to look out of. The decisions seem based on stopping things instead of creating excitement and awe. I do pray I am dead wrong on that. I guess stopping things is progress too.

 

actually I think the lastest update did seem to create a bit of shock and awe.

[knowschad]

I understand our decisions won't always make sense from the outside looking in.

But without the outside, you will have no inside to look out of. The decisions seem based on stopping things instead of creating excitement and awe. I do pray I am dead wrong on that. I guess stopping things is progress too.

actually I think the lastest update did seem to create a bit of shock and awe.

More like, shock and, "awwww... why did they go and do that?!"

[+TripCyclone]

Thanks for the answer Nate. It's always helpful for users to have even a small idea of the basic process used to make these kinds of decisions.

 

Something I had been wondering about as I typed my thoughts in the release notes post yesterday. I realize that you guys would sometimes like to keep a few aces up your sleeves for future plans, but is there any way that when release notes are first posted, you could give us an idea of what is next on your agenda of things to tackle? For example, particular bugs that you are focusing on, or even feature requests that you are going to be looking into. As someone who has posted a few ideas myself, ideas that some agreed on and other just said why bother, the part that I haven't seen is how the idea is perceived on your end. Granted, it would take a lot of time and energy to respond to every single idea. But the simple act of saying "Hey everyone. Now that we've gotten this update done, here's a few items we are currently looking into." is helpful. It could even be turned into an opportunity for users to submit observations about those particular items.

 

For example. Let's say that you guys saw my post about two weeks or so ago about allowing users to create bookmark lists for trackables much like the feature allows for caches, providing a way for us to easily look in on travel bugs and geocoins that we may have come across without having to receive emails every time it is logged like we would with Watchlists. Now let's say that in April, you guys were to decide to see if that might be included in the next update. By posting that you were looking into that, you could give users an opportunity to comment on the idea, maybe suggesting something I hadn't thought of that could improve the idea. Or, if there was a lot of "don't really care about that", then you could always shelve the idea (of course, who would say that isn't an AWESOME idea ).

 

Just a thought on another way to a heads up on what's in the pipeline, and possibly gauge reactions to it.