Jump to content

Release Notes (Website: Multiple photos on draft or log) - May 15, 2017


Recommended Posts

Release Notes (Website only) - May 15, 2017

 

With this release we added the ability to include multiple photos with a draft or log on Geocaching.com. You can now upload up to 20 photos per log and can add additional photos by editing your log once it is posted.

 

Additionally, the new logging page on Geocaching.com will show the number of remaining favorite points available to award. Hover over the Favorite points heart to see the number available to award.

 

Nate I. and Nadja from HQ’s Product Team are watching the thread to answer questions whenever possible.

 

Any posts in this thread should relate to features in this release. Please direct unrelated comments to other appropriate threads. Thanks!

Link to comment

Thank you for providing this additional functionality, but sadly it still doesn't allow the photos to be captioned. Twenty photos without captions are just pretty pictures, they don't tell the story I'm trying to relate to the CO and future finders. Photos in logs aren't decorative, they're meant to convey part of the finder's narrative.

 

You mentioned editing the log afterwards, but currently the log edit page is essentially the same as the old log creation page and may well be the same piece of code. Since part of the stated motivation for all this is to remove old code, will it be subsequently replaced with the new style page with all the same limitations?

Link to comment

Why there is not an option to fill in caption of photos, when uploading/adding?

^This

While it's great that you can now add more than one photo, users will still need to go to the old edit form to add captions to each photo.

 

I sincerely hope TPTB aren't leaning towards eliminating captions entirely. That would be a big blow to the cache-logging experience.

 

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default? Don't make the mistake of trying to give users a "clean" experience. It will be much better if you give the users a "useful" experience.

Link to comment

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default? Don't make the mistake of trying to give users a "clean" experience. It will be much better if you give the users a "useful" experience.

 

Personally I prefer to see it hidden unless I hover over it, otherwise it would get a bit busy. I have hundreds of unused favorite points, so for me at least the count is pretty much irrelevant. I know many others don't have a cache of unused points to give out so your workflow may be different.

Link to comment

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default?

Personally I prefer to see it hidden unless I hover over it, otherwise it would get a bit busy.

Honestly, I don't have a strong preference either way because I don't hand out FPs very often and have no shortage of available FPs. However, since many recent changes have been focused on making things work better on mobile devices, it seems odd to then make this feature require an action that isn't possible on a mobile device. I just tested this on my iPhone, and it acts a bit different. On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements. This doesn't seem very intuitive. I would think most users would expect a single tap to add a FP, not a double-tap. If the count were already visible, only a single tap would be required.

Link to comment

Send it back to the kitchen, this isn't cooked right.

 

Seriously, no captions?

 

Seriously?

 

Something is wrong at Groundspeak, and I'm worried about the fate of this game.

 

HQ has already indicated they are making multiple releases. I expect more will be added in the next couple weeks.

Link to comment

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default?

Personally I prefer to see it hidden unless I hover over it, otherwise it would get a bit busy.

Honestly, I don't have a strong preference either way because I don't hand out FPs very often and have no shortage of available FPs. However, since many recent changes have been focused on making things work better on mobile devices, it seems odd to then make this feature require an action that isn't possible on a mobile device. I just tested this on my iPhone, and it acts a bit different. On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements. This doesn't seem very intuitive. I would think most users would expect a single tap to add a FP, not a double-tap. If the count were already visible, only a single tap would be required.

 

I would assume that the web developers aren't prioritising mobile device users for the reason that most people on a mobile device will log finds via an app, whether it's the official app or a 3rd party app via the API. Granted, I realize the whole motivation behind these website upgrades is to make the website more mobile friendly, but that's because some of the information and functionality that we can get from the website is not yet available through any app (example: viewing yours or another cacher's profile). I've always been of the opinion that the app and website need to be nearly identical in function.

Link to comment
On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements.

How clear is it that the first tap does not grant the favorite point?

 

If you've never tapped it twice, ever, would you know to expect a filled heart to mean it's been granted?

Link to comment

Multiple photos - better. Captions still needs to be done, and there's no change to the 'Report a problem'/'Needs Maintenance' issue that's of any value. Most of my NM and NA logs required more than a canned message, so this has no utility for me at all and I'll still need to return to the old logging screen to log these things properly.

 

So, a plus point for the improvements but this is still a long way from 'Ready for service'.

 

I don't understand why the all the issues raised in the forum haven't been addressed before a new release is put out, so minus one plus point for that.

Edited by gasbottle
Link to comment
On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements.

How clear is it that the first tap does not grant the favorite point?

Not very. When you first load the page, the FP icon is an empty heart with a grey outline. When you tap it the first time, the outline changes to green and the text "# available" appears underneath, also in green. I'm sure many could mistake the colour change to be associated with a state change, but it actually isn't.

Link to comment

 

Additionally, the new logging page on Geocaching.com will show the number of remaining favorite points available to award. Hover over the Favorite points heart to see the number available to award.

 

 

I know that there's complaints about making changes to satisfy app users, but I use an iPad and not a PC.

There's no way to hover without a mouse...

 

Edit: just say that a tap / double tap displays the number. Very very non intuitive...

 

Any way to include the number of favorite points in the heart? That way it's always there and doesn't take up any screen real estate...

Edited by WearyTraveler
Link to comment

...there's no change to the 'Report a problem'/'Needs Maintenance'...

Some people have already pointed out the ambiguity surrounding the "Needs maintenance" label and how it looks like a notice rather than an option, but I discovered today that it's even worse. When you hover over that label, the tooltip that's displayed says "This geocache needs maintenance". This would seem to further reinforce a misconception that it's a notice.

 

The label really needs to be changed to "Report a problem" and the tooltip to "Report a problem with this geocache".

Link to comment

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default?

Personally I prefer to see it hidden unless I hover over it, otherwise it would get a bit busy.

Honestly, I don't have a strong preference either way because I don't hand out FPs very often and have no shortage of available FPs. However, since many recent changes have been focused on making things work better on mobile devices, it seems odd to then make this feature require an action that isn't possible on a mobile device. I just tested this on my iPhone, and it acts a bit different. On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements. This doesn't seem very intuitive. I would think most users would expect a single tap to add a FP, not a double-tap. If the count were already visible, only a single tap would be required.

 

If the count were already visible, no tap would be necessary...

 

And - if they can fill out the numbers after a tap, they can easily bypass the tap and just let the number be visible...

Link to comment

Send it back to the kitchen, this isn't cooked right.

 

Seriously, no captions?

 

Seriously?

 

Something is wrong at Groundspeak, and I'm worried about the fate of this game.

 

We're still collecting feedback and discussing the best ways to address photo captions. I admit it seems simple on the face of it, but when you factor in the mobile app and draft logs it complicates the solution a bit. Just know that we're considering all the options and listening to your concerns.

Link to comment
I just tested this on my iPhone, and it acts a bit different. On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements. This doesn't seem very intuitive.
That sounds like the way the VoiceOver screen reader for blind users works on iOS devices. The first tap/drag/touch gets it to tell you what something is. Then you tap it again to activate the selected control.

 

And no, it isn't very intuitive for sighted users who don't understand how it works.

 

And it might even contradict the standard UI guidelines to have normal apps behave that way when there is no screen reader involved.

Link to comment
On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements.

How clear is it that the first tap does not grant the favorite point?

Not very. When you first load the page, the FP icon is an empty heart with a grey outline. When you tap it the first time, the outline changes to green and the text "# available" appears underneath, also in green. I'm sure many could mistake the colour change to be associated with a state change, but it actually isn't.

 

This is all because the the different way that the event model works between desktop/mouse and mobile/touch. Mouseovers aren't a touchscreen thing, so special event handling has to be developed to provide a mobile-friendly interaction - that doesn't seem to have been done (yet) on this button. Having simultaneous mouse and touch events on a single object can be a pain to manage.

* This is exactly the coding I've been developing the week or so in a new framework for my company's intranet. Interface events have to be separated from UI functionality so they can be tied effectively to actions depending on whether it's a mouse or a touch event, especially when you're developing your own HTML widgets to override browser defaults.

 

I'm assuming the 'tooltip' mouseover/hover style events will be dealt with as soon as they have more mobile testers run through those pages.

Edited by thebruce0
Link to comment

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default?

Personally I prefer to see it hidden unless I hover over it, otherwise it would get a bit busy.

Honestly, I don't have a strong preference either way because I don't hand out FPs very often and have no shortage of available FPs. However, since many recent changes have been focused on making things work better on mobile devices, it seems odd to then make this feature require an action that isn't possible on a mobile device. I just tested this on my iPhone, and it acts a bit different. On the first tap of the heart, the heart remains empty and the "# available" text appears underneath it. Only on a second tap does it change to a filled-in heart and the count decrements. This doesn't seem very intuitive. I would think most users would expect a single tap to add a FP, not a double-tap. If the count were already visible, only a single tap would be required.

 

I would assume that the web developers aren't prioritising mobile device users for the reason that most people on a mobile device will log finds via an app, whether it's the official app or a 3rd party app via the API. Granted, I realize the whole motivation behind these website upgrades is to make the website more mobile friendly, but that's because some of the information and functionality that we can get from the website is not yet available through any app (example: viewing yours or another cacher's profile). I've always been of the opinion that the app and website need to be nearly identical in function.

I must strongly disagree. The app should be focused on being used in the field, when in the process of looking for caches, whereas the website is more something that's used at home after a day's caching. For the latter, I like to compose a decent multi-paragraph log, so the now-lost formatting buttons would be useful, sort through my photos, do any needed cropping and straightening, and add the captions and descriptions needed to convey the story of my caching adventure.

 

Creating a cache is also something that's best done at home and I hate to think how cut-back and dysfunctional an app version of that would be. Although I could see merit in having some of the field work in creating a cache available in the app, such as taking coordinates, averaging, making notes and taking photos, but the cache page creation process itself really should be done at home and should remain designed for that environment.

 

Above all, please stop removing functionality from the website just because it can't easily be replicated in the app or is difficult to do with current generation phone browsers.

Link to comment

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default? Don't make the mistake of trying to give users a "clean" experience. It will be much better if you give the users a "useful" experience.

Personally I prefer to see it hidden unless I hover over it, otherwise it would get a bit busy. I have hundreds of unused favorite points, so for me at least the count is pretty much irrelevant. I know many others don't have a cache of unused points to give out so your workflow may be different.

So why not make it a user-settable option? That way people who want to see it can, and those who don't want to see it don't have to.

Edited by Nylimb
Link to comment

We're still collecting feedback and discussing the best ways to address photo captions. I admit it seems simple on the face of it, but when you factor in the mobile app and draft logs it complicates the solution a bit. Just know that we're considering all the options and listening to your concerns.

Good to hear, thank you. :) (BTW why not mention it in the original post right away and save lots of questions when you knew everybody was expecting this to be fixed along with the ability to attach multiple images?) Please do not forget the descriptions. They're not used that often but sometimes one feels the need to precisely describe the photo.

 

I am as well for changing the "Needs maintenance" to "Report a problem" as stated in post #14.

 

EDIT: on czech forum people with worse internet connection complain about problematic loading of the new logging page. Sometimes they have to refresh the page three times until it finally gets loaded. They don't have troubles with other pages on geocaching.com (like cache pages, etc.) This has also happened to me.

Edited by Pontiac_CZ
Link to comment

I logged a NM last weekend on a cache with previous problems. The state I found the cache in was new. If I'd only posted a NM with the new logging system then it would not have been clear that this is a new issue. Furthermore, adding a photo with an actual caption makes the problem much clearer. I think both, a caption for photos and a proper problem reporting system needs to be in place again.

Edited by terratin
Link to comment

Why there is not an option to fill in caption of photos, when uploading/adding?

Please accommodate adding captions to photos and retain the ability to use the 'old' logging page to edit logs until the 'new' logging page allows photo captions.

 

As for the FP count, that's great, but why hide it until you hover over it? Why not just display it by default? Don't make the mistake of trying to give users a "clean" experience. It will be much better if you give the users a "useful" experience.

+1 - I'd prefer that the "n available" / "n remaining" labels be shown at all times. On my Android phone, when I tap the heart icon, then it shows "n available" for a split second, then the icon fills green and shows "n remaining".

 

Some people have already pointed out the ambiguity surrounding the "Needs maintenance" label and how it looks like a notice rather than an option, but I discovered today that it's even worse. When you hover over that label, the tooltip that's displayed says "This geocache needs maintenance". This would seem to further reinforce a misconception that it's a notice.

 

The label really needs to be changed to "Report a problem" and the tooltip to "Report a problem with this geocache".

+1 - The "! Needs Maintenance" label seems like an alert - telling the user that "this cache needs maintenance". I think it would be more recognizable as an action button if it read "! Report a Problem".

Link to comment

Send it back to the kitchen, this isn't cooked right.

 

Seriously, no captions?

 

Seriously?

 

Something is wrong at Groundspeak, and I'm worried about the fate of this game.

 

We're still collecting feedback and discussing the best ways to address photo captions. I admit it seems simple on the face of it, but when you factor in the mobile app and draft logs it complicates the solution a bit. Just know that we're considering all the options and listening to your concerns.

Just throwing this out there that other apps have allowed multiple photos and all with the ability to add captions and descriptions on every one. Cachly for instance has allowed for multiple photos attached to logs and capability to add a caption since it's first release a year and a half ago. If other app developers have added the capability, I would think your developers would be highly capable of adding this feature to the app as well.

Link to comment

Send it back to the kitchen, this isn't cooked right.

 

Seriously, no captions?

 

Seriously?

 

Something is wrong at Groundspeak, and I'm worried about the fate of this game.

 

We're still collecting feedback and discussing the best ways to address photo captions. I admit it seems simple on the face of it, but when you factor in the mobile app and draft logs it complicates the solution a bit. Just know that we're considering all the options and listening to your concerns.

Just throwing this out there that other apps have allowed multiple photos and all with the ability to add captions and descriptions on every one. Cachly for instance has allowed for multiple photos attached to logs and capability to add a caption since it's first release a year and a half ago. If other app developers have added the capability, I would think your developers would be highly capable of adding this feature to the app as well.

 

You'd think so, wouldn't you...

Link to comment

I must strongly disagree. The app should be focused on being used in the field, when in the process of looking for caches, whereas the website is more something that's used at home after a day's caching. For the latter, I like to compose a decent multi-paragraph log, so the now-lost formatting buttons would be useful, sort through my photos, do any needed cropping and straightening, and add the captions and descriptions needed to convey the story of my caching adventure.

 

Creating a cache is also something that's best done at home and I hate to think how cut-back and dysfunctional an app version of that would be. Although I could see merit in having some of the field work in creating a cache available in the app, such as taking coordinates, averaging, making notes and taking photos, but the cache page creation process itself really should be done at home and should remain designed for that environment.

 

Above all, please stop removing functionality from the website just because it can't easily be replicated in the app or is difficult to do with current generation phone browsers.

 

+111111

This every day. Its completely stupid to design the actual website for phone/app users.

Link to comment

I must strongly disagree. The app should be focused on being used in the field, when in the process of looking for caches, whereas the website is more something that's used at home after a day's caching. For the latter, I like to compose a decent multi-paragraph log, so the now-lost formatting buttons would be useful, sort through my photos, do any needed cropping and straightening, and add the captions and descriptions needed to convey the story of my caching adventure.

 

Creating a cache is also something that's best done at home and I hate to think how cut-back and dysfunctional an app version of that would be. Although I could see merit in having some of the field work in creating a cache available in the app, such as taking coordinates, averaging, making notes and taking photos, but the cache page creation process itself really should be done at home and should remain designed for that environment.

 

Above all, please stop removing functionality from the website just because it can't easily be replicated in the app or is difficult to do with current generation phone browsers.

 

+111111

This every day. Its completely stupid to design the actual website for phone/app users.

 

That's not what I meant. There are features of the website that I feel could be added to the app. Bring the app up to the level of the website rather than degrade the website down to the level of an app.

Link to comment

Not really to do with this release, but the release notes for the new logging feature is locked so....

 

When using the new logging feature to log a cache which is locked (Yes the moving caches which have just been killed) the new method just gives a page with no options selectable in the dropdown box, there's nothing to actually say why there are no options. IMO there should be a notice stating that it's not possible to post a log as the cache has been archived - as the old log page did.

Link to comment

(Yes the moving caches which have just been killed)

Well, I guess they've all been killed. No more harmless exceptions allowed, I guess.

 

It's amusing that by doing this, they've exposed this silliness in the new form. I particularly like that you can enter a description and add pictures. And, yes, actually I do think this has to do with this release. Isn't it a bug report?

Link to comment

This Release Notes thread is for talking about the multiple photo upload and favorite point tracking features in the new logging workflow. There are threads open in the Geocaching Topics forum to discuss the moving caches that were locked today. Thanks.

Link to comment

This Release Notes thread is for talking about the multiple photo upload and favorite point tracking features in the new logging workflow. There are threads open in the Geocaching Topics forum to discuss the moving caches that were locked today. Thanks.

 

If that was aimed at me:

 

My post was about the inability of the new logging feature to handle locked caches, and as I pointed out the release notes thread for that original release is already locked so I can't report it on there.

Link to comment

...there's no change to the 'Report a problem'/'Needs Maintenance'...

Some people have already pointed out the ambiguity surrounding the "Needs maintenance" label and how it looks like a notice rather than an option, but I discovered today that it's even worse. When you hover over that label, the tooltip that's displayed says "This geocache needs maintenance". This would seem to further reinforce a misconception that it's a notice.

 

The label really needs to be changed to "Report a problem" and the tooltip to "Report a problem with this geocache".

 

Good comment. If HQ will not go back to allowing Needs Maintenance Logs that are independent of anything else you do on the cache page, then the option should indicate you want to report a problem with the cache.

 

At least they did one thing right with the new Needs Maintenance option - you can pick one of the canned messages and then edit it to say what the problem is.

Edited by Backwards Charlie from Austin
Link to comment

I think I found a bug with the new logging. When logging a cache, I accidentally clicked "Drop" for one of my trackables when I meant to select "Visit." Before submitting the log, I clicked Visit for that trackable and at that screen it was highlighted blue that "Visit" was selected. When I submitted the log, the trackable was dropped in the cache, even though I changed it to be a Visit log on the previous screen.

Link to comment

I think I found a bug with the new logging. When logging a cache, I accidentally clicked "Drop" for one of my trackables when I meant to select "Visit." Before submitting the log, I clicked Visit for that trackable and at that screen it was highlighted blue that "Visit" was selected. When I submitted the log, the trackable was dropped in the cache, even though I changed it to be a Visit log on the previous screen.

 

You did.

 

BUG: Accidentally Select Drop, Change to Visit, TB still gets Dropped

Link to comment

I think I found a bug with the new logging. When logging a cache, I accidentally clicked "Drop" for one of my trackables when I meant to select "Visit." Before submitting the log, I clicked Visit for that trackable and at that screen it was highlighted blue that "Visit" was selected. When I submitted the log, the trackable was dropped in the cache, even though I changed it to be a Visit log on the previous screen.

 

You did.

 

BUG: Accidentally Select Drop, Change to Visit, TB still gets Dropped

Yes, that was me that posted that there as well. I wanted to cover all my bases.

Link to comment

I think I found a bug with the new logging. When logging a cache, I accidentally clicked "Drop" for one of my trackables when I meant to select "Visit." Before submitting the log, I clicked Visit for that trackable and at that screen it was highlighted blue that "Visit" was selected. When I submitted the log, the trackable was dropped in the cache, even though I changed it to be a Visit log on the previous screen.

 

You did.

 

BUG: Accidentally Select Drop, Change to Visit, TB still gets Dropped

Yes, that was me that posted that there as well. I wanted to cover all my bases.

 

This has been fixed! Thanks for reporting Sherminator18.

Link to comment

I don't know whether this is a bug or by design, but I just noticed when attaching multiple photos to a log that the photos don't appear in the same order in which I attached them. My photos are intended to tell the story of my caching adventure and the order, usually chronological, is important. The only way to fix it was to go into the log edit page, delete all the out-of-order photos and start again.

Link to comment

I don't know whether this is a bug or by design, but I just noticed when attaching multiple photos to a log that the photos don't appear in the same order in which I attached them. My photos are intended to tell the story of my caching adventure and the order, usually chronological, is important. The only way to fix it was to go into the log edit page, delete all the out-of-order photos and start again.

Were you able to determine what was determining the order they would appear?

Link to comment

I don't know whether this is a bug or by design, but I just noticed when attaching multiple photos to a log that the photos don't appear in the same order in which I attached them. My photos are intended to tell the story of my caching adventure and the order, usually chronological, is important. The only way to fix it was to go into the log edit page, delete all the out-of-order photos and start again.

Were you able to determine what was determining the order they would appear?

No, it seemed to be random. The original file names were in correct order alphabetically, as were the timestamps, so it wasn't using those, and obviously at that point there were no captions that it could've been sorting by.

Link to comment

I don't know whether this is a bug or by design, but I just noticed when attaching multiple photos to a log that the photos don't appear in the same order in which I attached them. My photos are intended to tell the story of my caching adventure and the order, usually chronological, is important. The only way to fix it was to go into the log edit page, delete all the out-of-order photos and start again.

Further to this, I've just noticed that in a few of my old logs, the photos have become shuffled. After a bit of experimenting, it looks like they're now sorted by the time of the last edit, so if I edit, say, the caption, that photo moves to the end of the list. Not good.

 

Edit to add: It looks like the order of photos on the "edit log" page is that in which they were created, but in the log on the cache page they're shuffled according to the last edit time.

Edited by barefootjeff
Link to comment

The classic logging experience gets the order right, and this is essential for telling a story properly.

Forget what I said. The previous poster was right - this used to work, but now it's broken. Edit an image, say to touch up the caption, and the order is scrambled. No more sequencing by order entered.

 

I consider this a big FAIL. You broke my stories!

 

EG, very broken. Or here, introductory picture now at the end.

 

Please please fix.

Edited by Viajero Perdido
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...