Need to rethink and finalize the image/embed selection process.

[stephdau]

With @azaozz's work to get TinyMCE loaded in PT, I think we might have to drop the current image selection block altogether, and come up with something else. Not entirely sure what though.

Adding a tab to the media library to present the discovered images is possible, but it also takes them away from immediacy, and a bunch of clicks away. Not sure what UX would be best. At all.

It gets strange otherwise if someone presses a page, and we use oEmbed and in-editor previews for video embeds, for example.

[danielbachhuber]

Why is there such emphasis on pulling an image out of the page you're linking to, and including an image in the post generally?

Do you have user stories you're working from? I know that mobile is a priority, and it seems like the mobile use case for Press This could be substantially different than the desktop use case.

[MichaelArestad]

@danielbachhuber A few reasons primarily.

1. It's pretty awesome when it finds a nice image. It's also one tap to remove it.
2. I think it can help with discoverability. The current core Press This allows adding media from a site, but it's pretty hard to find. I didn't even know it was there for quite some time. Showing an image and hitting a button (with whichever UI we come up with) can highlight the user has the option of selecting media from the pressed page.
3. It will ideally allow quick adding of a photo from mobile. In other words, it could be an ideal app for publishing quick photos, statements, whatever from your phone with as little resistance as possible. It's current iteration is pretty darn nice for that (if you can figure out how to add it to your phone's home screen).

Do you have user stories you're working from?

We have six interviews here and many suspicions we'd like to test.

I know that mobile is a priority, and it seems like the mobile use case for Press This could be substantially different than the desktop use case.

It could definitely be. That's why I want to get some usability testing going as soon as we have TinyMCE integrated to find out if our suspicions were on target or waaaaay off.

[danielbachhuber]

It's pretty awesome when it finds a nice image. It's also one tap to remove it.

It would be interesting to test how often it finds a nice image. If it only finds a nice image 20% of the time, then 80% of the time I have to click the icon. In this case, it would be better to make it opt-in (e.g. a button that says "find me an image" or similar).

Showing an image and hitting a button (with whichever UI we come up with) can highlight the user has the option of selecting media from the pressed page.

I had no idea I could click the image to change it to another image. I don't think there is an existing pattern in core for this. We should also user test.

It will ideally allow quick adding of a photo from mobile. It's current iteration is pretty darn nice for that (if you can figure out how to add it to your phone's home screen).

Yes, I understand and agree with this. But I think this behavior is not insignificantly distinct from desktop (where image blogging is one activity of many).

[MichaelArestad]

It would be interesting to test how often it finds a nice image. If it only finds a nice image 20% of the time, then 80% of the time I have to click the icon. In this case, it would be better to make it opt-in (e.g. a button that says "find me an image" or similar).

Currently it really depends on the site. For things like Github, Make blogs, etc, it's usually just a series of avatars. I know I really want to improve the way we guess. We can probably fairly intelligently rule out avatars and those kinds of images for the initial guess.

[danielbachhuber]

For things like Github, Make blogs, etc, it's usually just a series of avatars. I know I really want to improve the way we guess

If you had a corpus of data from posts published using Press This, it would make it much easier to solve. I'd be happy to offer mine as a dump — not sure if WPcom has been tracking posts created with Press This.

[stephdau]

If it only finds a nice image 20% of the time, then 80% of the time I have to click the icon.

There's already logic to base the selection of the most likely image based on in-source cues such as Open Graph and Twitter Cards (amongst others):

• https://github.com/MichaelArestad/Press-This/blob/master/js/bookmarklet.js#L66
• https://github.com/MichaelArestad/Press-This/blob/master/js/app.js#L169

Those represent what the content producers defines as the most valuable pict in the page. There are equivalent tags for embeds.

it would be better to make it opt-in (e.g. a button that says "find me an image" or similar).

We can, when no such quality meta data has been detected. Maybe we can assume, if some was.
I'm not attached to opt-in vs opt-out, personally, so long as the UX is quick to it when I need it, since that's my personal full-time use-case for Press This. :)

Side note: [Gr]avatars are currently being implicitly detected, so can be just as easily discarded.

[stephdau]

One more thing, re: "pressing something" vs mobile experience: one does not nullify the other. Currently, if no URL is being passed, and PT is being accessed directly, we prompt the user to paste a URL in a subtle text field at the top of the page. I found this was the cleanest way to enabling "pressing" something on mobile. Browse a page -> copy its URL -> Open PT directly (I do it from bookmark on my mobile launcher) -> paste URL in field. Bookmarklets on mobile suck, since it often takes the user away from the actual page to load another tab or so, and can no longer access its content (in my experience playing with them, not an actual case study).

[danielbachhuber]

Bookmarklets on mobile suck, since it often takes the user away from the actual page to load another tab or so, and can no longer access its content (in my experience playing with them, not an actual case study).

Agree

[MichaelArestad]

I think with the new UX, this is solved.