Closed Cybernide closed 1 year ago
Assigning to @Cybernide until we're ready to test, since @jaydeepsingh25 indicates this is a quick thing to do, but we'd want to do it in a separate branch with a custom build for testing, since reverting it out of main may not be trivial.
@Cybernide @jaydeepsingh25 I just spoke with @21satvik , and he is moving forward on trying to convert the extension to work on desktop and mobile Safari. Due to lack of context menus, photos are not triggerable on iOS. If we end up doing this on the desktop extension, ti would solve the UI problem on mobile as well. @21satvik - I know you're trying the extension on maps and charts as we discussed this morning, to see what happens with those, but if the photos not being triggerable becomes a blocking issue, please let us know.
Ah ok - yes, if mobile platforms are on the immediate horizon, then it makes sense to phase out the context menus as I expect that in (the ideal) case someone would like to have both desktop and mobile versions of the extension, we would want more consistency between those interfaces.
As much as I fear the technical uncertainty of dynamically inserted buttons, I think the lack of discoverability with context menus alone is reason enough to make the switch. All of these other considerations just make it a stronger argument IMO.
I'm also very wary of the buttons, but I think that lack of discoverability is (after installation) the biggest hump for users
Agree with all of the above, except that I'd say providing an optimized experience on each platform is more important than consistency for consistency's sake. I also fear issues with adding buttons, but I haven't heard a convincing alternative presented yet. I'd rather have people complain about it but be able to use it, rather than simply be unable to use it at all! We could also contemplate making buttons on graphics a setting if we think there are strong reasons to allow poeple to turn it off. This might also help with debugging, since we could at first default it to off, test, and enable by default when we think it is a clear improvement over what is already deployed.
Hey, I've never said that buttons are without issue! I'm only advocating for them as a "suspected best option"
In any case, doing a mockup
I have tested the IMAGE extension on an iPhone for maps and charts and observed that the Interpret button appears for both. So unlike graphics, I have the option to send interpret requests. You can find additional details about my findings at this link. To ensure a consistent experience across all devices, using buttons seems like a viable option.
Wireframed in the linked story. Closing.
As pointed out by @JRegimbal here: https://github.com/Shared-Reality-Lab/IMAGE-browser/issues/261#issuecomment-1351404717, and as we've found bugs and issues when doing this for charts/maps in firefox, or on some pages with obscuring content, etc. this is not necessarily easy to do well. Agree with @Cybernide that some visual rot might be ok if this is much better functionally, but we also cannot create something so horrific that sighted users, who may be evaluating IMAGE for others (e.g., mobility specialists) reject it out of hand.
@jaydeepsingh25 Can you please provide a rough estimate of the time it would take to put a temporary hack in the nightly extension that would put a button on every photo on webpages that would normally get a "Get IMAGE rendering" right-click option? I think this will immediately flag a ton of issues including the "tiny styling graphics" issue @JRegimbal raises above. Note that there is an existing backlog item for removing the right-click option for useless photos, which we'd probably need to bring into a sprint if we go this route (https://github.com/Shared-Reality-Lab/IMAGE-browser/issues/66).
@Cybernide If this is non-trivial to do even without tweaking to exclude photos by some heuristic, then we'll have to look into mocking this up, since I wouldn't want to burn a ton of development time until we're more convinced that this route will pay significant discoverability/usability benefits.
@Cybernide We also need to think about what text to put on the button, since the existing context menu text is likely to be very confusing, and putting it in a button doesn't seem like it would be much better?