This is a follow up post, showing the current and final implementation – at least for the upcoming picu Pro release.
I think we made some great improvements:
As you can see, we removed the need to click to reveal the stars. They are constantly visible, if set.
Internal testing showed, that users can much easier discern the number of stars, if shown the actual stars instead of a number next to a single star.
A big change was moving the filter and grid size UI from the bottom status bar to the top. While I really loved the old filter implementation, this change will allow us to add more filters in the future and – at the same time – make some room at the bottom for other, upcoming UI challenges.
Star and selected/unselected filters can also be combined, which will allow for a much more fine grained selection process.
Stars can also be changed in the lightbox view:
Besides clicking on the star rating you can also use your keyboard by typing a number between 1 and 5 to change the star rating.
Star rating & filter will be a Pro feature and we are very excited for this update!
Until now filtering images in a collection was only possible between “selected” or “unselected”.
I wanted to make this more flexible and landed on star rating/filtering.
Star ratings are pretty common and universally understood, although the usual use case is rating products or movies. Still, the concept remains the same: More stars mean “better”. Also, photo management software like Adobe Lightroom have supported star ratings basically forever.
This will make the selection process much more flexible, especially when dealing with lots of images. For example, it will allow making multiple selection rounds, assigning one star in the first round, two in the next, etc., ending up with a final selection which can then actually be selected – and sent to the photographer.
Below you can see a video of the current implementation of star ratings for individual images and the filter:
Please note, that this is still in early stages, so the implementation will probably change for the final release.
With picu 2.3.0 and picu Pro 1.4.0 collections do no longer close automatically. Before collections would close once the last client approved their selection. With the introduction of client (self) registration, this no longer made sense.
We still wanted to make it easy for the photographer to close the collection once everyone is done.
So we added a new “Close Collection” button to the notification email, that the photographer gets, when a client approved a collection.
This button will only be added once the last client has approved their selection.
And this is what it looks like:
The button will be part of the picu Pro 1.4.8 release.
picu collections are never meant to be public, that is why we remove them from XML sitemaps, have robots meta directives set to noindex, etc..
(Short excursion: For various reasons we cannot set our collection post type to ‘public' => false, because they are public, as in they need to be displayed in the front end – just not for everyone.)
We try to support the most common SEO plugins. And by support I mean, make sure that users do not accidentally add their collections to search engines.
We implemented this for the Yoast SEO plugin a long time ago, but until now our custom post type still showed up in the Yoast settings. The settings for picu collections didn’t do anything, but they were still visible, which made it confusing for our users. (I even created an issue on GitHub years ago.)
We recently found this new filter wpseo_indexable_excluded_post_types, which not only allows us to excludes picu collection from being indexed by Yoast, it finally also did the trick of removing collection from the Yoast settings. 🥳
This is the code we used:
/**
* Exclude collections from Yoast SEO indexable creation.
*
* @since 2.3.6
*
* @see https://developer.yoast.com/features/indexables/indexables-filters/#post_types
*
* @param array $excluded Array of excluded post types by name.
* @return array The filtered post types.
*/
function picu_do_not_create_indexables_for_collections( $excluded ) {
$excluded[] = 'picu_collection';
return $excluded;
}
add_filter( 'wpseo_indexable_excluded_post_types', 'picu_do_not_create_indexables_for_collections' );
With picu Pro you can add markers and comments to individual images.
We now also display the date, of when the comment was made.
This is what it looks like in the frontend:
Backend:
This is only the very first step to enable a more interactive workflow. The goal is to allow a back and forth of messages, discussing individual images between client and photographer – and finally between several different clients as well.
With picu Pro you can set a selection goal, so either the exact, minimum, maximum or inside a specific range of the number of images your clients need to select.
Until now, the goal was communicated in the email or the info panel, but there was no clear indication during the selection process. Only when the user wanted to approve the collection, did picu display an alert:
From a user perspective this could be a bit frustrating, especially if they didn’t fully read the email and just now learned about the number restriction.
So, we wanted to add an indicator, when the current selection wasn’t hitting its intended target.
We decided to go with a very minimal, unintrusive, yet visible icon.
Claudio’s sketch:
When implementing it, I added a slight animation, when the indicator is first shown:
Once the goal is reached, the alert is hidden:
We hope this will mitigate a possible source of frustration when making a selection.
We got a lot of answers and some really great ideas back in return, and wanted to share a quick update on the current status, what we learned and what decisions we made so far.
Some quick facts from the survey:
With 87%, almost anyone wants to be able to sell Digital Files, followed by Prints (66,7%) and Albums (45,8)
Existing use of e-commerce plugins is split fairly even between 45,8% with no e-commerce plugin at all and 41,7% on WooCommerce
Same for Payment Gateways, where 69,6% are experienced with PayPal and 60,9% with Stripe
As for the detailed workflows, we left the question intentionally wide open to get a better picture of what people envision when they think of selling images.
What stuck out the most, is that the actual payment functionality and extended shop settings seem to be a nice bonus for many but the most important step is communicating prices to clients and make them aware what options they have. This came as a little bit of a surprise but – together with the numbers above about existing shop usage – gave us a much clearer picture of what we should build first.
So, here’s what we decided to tackle first:
Set a price per image in a gallery
Set a bundle price for a gallery with options to upsell additional images
Display those prices in the frontend to the client
Display the final total in the approval form (which in this case becomes more of a cart/checkout)
Display ordered images in the backend for the photographer
Bonus: A very basic first integration with Stripe and/or Paypal
This functionality will cover a lot of ground and will allow our customers to sell images through picu, but we’re not going to stop there. Technically, this will just be a first stepping stone in the direction of more extensive e-commerce integrations.
To make sure we get this right, we plan to release a beta version first to let a few people test this properly, for which some of you already volunteered (thanks everyone!). If you would like to be added to our pool of beta testers, please get in touch.
The analytics data we tracked so far was pretty minimalistic. While we have added some UTM tags in the past, the usage of them was inconsistent to say the least.
So, when we set out to improve the way we display feature hints and generally experiment a bit more with other things from inside the plugin, I wanted to make sure that we also get some usable data about those links.
First things first: I googled about UTM best practices and looked at what other plugins are doing and as with many things, there are a lot of different ways how you can go about this, none necessarily more correct than the other.
But I needed to decide what’s best for us, so I did what I often do in such situations: I wrote down a list of the most important questions that I want answered.
Do people click more on links from some screens in the plugin than from others (settings VS editor screens for example)
With these goals in mind, I started looking for the technical implementation.
Next: Use a Link shortener
In the past, when we added UTM parameters to links, we hardcoded them into our plugin code, readme files or wherever else we put them. While this kind of worked, it made every change dependent on us pushing a new version out and then also wait until people upgraded to that new version. This can take some time (or in some cases never happen) and makes the data unreliable.
The solution to this is using a link shortener, where we can define shortlinks like go.picu.io/some-link which then get redirected to the proper URL including all of the needed UTM tags. These shortlinks are then place wherever we need a link to our website. We decided to use the open source and self-hosted “YOURLS” but you could also use a service like bitly and get the same result.
Now, if we want to change anything in regards to those UTM tags in the future, maybe rename a tag or even add a new one, we can simply update the target URLs in our shortener and those changes will be live immediately. No need to push any code or wait for any upgrades to happen.
UTM Strategy
After I wrote some of my initial ideas down, a good friend – who happens to be a Digital Analytics Pro and eats this stuff for breakfast – sat down with me and helped me a lot to unwhirl my own thoughts and get this started. Thanks Boris!
As said above, there are various ways to structure your UTM tags, and those can go from pretty simplistic all the way up to very, very complicated setups. Our old setup was too minimalistic, but I also don’t wan’t to overcomplicate things, so we needed to find something in the middle.
As a baseline, here’s what we did in the past, with our old “setup”:
UTM parameter
Description
utm_source
picu_plugin – for all in-plugin links wordpress.org – for links coming from the plugin repository (I think these are added by default by wp.org?)
utm_medium
pro_hints – all hints we placed inside the plugin (things like “Did you know you could do X and Y with picu Pro?”) pro_metabox – our main “banner” that we show in the metabox of the wp editor screens
And that was about it. While this gave us some data, there was a lot to be desired as well.
For example, we could see if pro_hints where clicked, but could not differentiate between them.
So, without further ado, here’s what we ended up with, at least to begin with:
UTM parameter
Description
utm_source
Where is this link coming from, at this point we’ll mostly have:
picu_plugin – for all in-plugin links wordpress.org – for links coming from the plugin repository email – our own newsletter
utm_medium
We use this for the type of link. This will certainly evolve, but so far we use:
feature_hints – all feature hints inside the plugin settings_banner – banners on the picu settings page for pro features settings_docs – help links from settings to our documentation pro_metabox – our main “banner” that we show in the metabox of the wp editor screens
utm_campaign
A descriptive title for the campaign, for easier handling this will often be the same as the slug of the shortlink, for example:
more-control – is used as the campaign for the shortlink go.picu.io/more-control
utm_term
The screen this link was placed on in the plugin, like:
(not used so far, but might be for things like an A/B test or if we want to differentiate between a link on an image and one on a text etc.)
This new structure has been live for two days only, so it’s too early to tell if it works as I hope or what adjustments we need to make, but I’m optimistic and look forward to getting some more insights.
If you use a similar structure yourself (or even a completely different one), or have anything else to add, please let me know!
I worked on improving a particular function on the collection edit screen: Adding a client to an open collection.
This is what the previous modal looked like:
This is the new version:
I updated this dialog with the following features:
Adding a name field. (Which is already possible for clients themselves in the front end, so this establishes feature parity)
Making the sending of the email optional. (As some clients prefer to send collection links through other channels, it makes sense to make this optional here as well.)
I also made the checkbox somewhat dynamic, by only allowing it to be checked, if the email field is not empty:
(Could be improved by checking if the input is actually a valid email address.)
Yesterday we sent out a newsletter asking for feedback from our users about e-commerce integration into picu.
Selling images directly through picu, as part of the proofing workflow, has been one of the most requested features and we feel like it is finally time to get to work on it.
But we want to make educated decisions on which features make the most sense for the majority of our users – hence, the survey.
So if you are a picu user and have a specific workflow in mind, please fill out the survey, and let us know! Cheers!
PS: Quick note, because it came up in some of the survey replies already: The existing, easy-to-use proofing workflow will always be the core of picu. E-commerce will extend the workflow for photographers who need/want it. If proofing is everything you need, skip right along.
We decided to simply describe what the setting does – as it should be.
But we opted to also include a help link to our docs page, where we provide more information about the whole registration process.
I think this makes a lot of sense, and we should have provided that info from the beginning to make it clearer, especially to existing picu users, how the new process works.
Here’s the final setting, which we will ship, hopefully later today:
With our last release we added a registration form, so that clients could identify themselves before making a selection. This enables the photographer to share the same link with multiple clients – or even allow the client to share the link with colleagues, etc.
We also added a setting whether entering an email address was required during registration. Unfortunately the setting and the registration form were somewhat confusing.
Many users thought that this option would turn the registration feature on or off. What made this additionally confusing was the fact, that the registration form did not reflect the setting.
The previous setting:
The previousregistration form:
I updated the setting to
make it clear, that it only controls, whether an email address is required during registration
I added a note, explaining that a confirmation email is always sent if an email address is entered – whether the field is required or not.
The updated setting:
This might not be final, but I think it is already much clearer than the previous version.
The updated registration form (email not required):
I made it clear, that the email field was optional and updated the intro paragraph to not explicitly mention the email anymore.
As requested by Florian, let’s also share some of the progress we’re making on the marketing & design side of things, first and foremost towards our new website.
The original site was launched 8+ years ago and only got some minor changes since, so by the end of last year I decided it’s time to give it some love, scrap it altogether and start anew.
In this first post I want to share the overall goals I initially set for the redesign as well as some early screenshots:
Modern, professional & friendly look: The old site feels more and more out of date and even a little unprofessional in some places.
Make it easy and fun to edit content: Because the harder it is for us to write on it, the less we actually do. This should also make it a lot easier to experiment, add new landing pages fast or even do some A/B testing in the future (which would have been a total pain to do right now).
Make it a little more personal: I just really like it if I see some personality on any website and it’s a huge turnoff for me, if I can’t see who’s behind a company.
Conversion Tracking: I joked in a discussion at WordCamp Europe that it feels like we don’t even throw things at the wall and see what sticks, but even worse: we throw it behind our backs without even looking what sticks. While this is certainly a little exaggerated, it is definitely something we need to improve, and the new site is the perfect opportunity to finally get at it.
Of course, there lots of other things and smaller “sub-goals”, like adding more social proof, or making it performant or as accessible as possible, but those are basic principles or supporting the above goals.
Without further ado. Here’s some teaser screenshots, I’ll share some more on the thinking behind it all very soon.
Continuing with improving the in-plugin banners, I am today looking at the ones we display on our collection edit screen.
So far they look like this (red highlight added to make the position obvious):
We randomly display different Pro features here:
I quite like those, they are very unobtrusive and also kind of playful with the eyes.
On the other hand, they should probably be more obvious/in your face, to do their job better. (We still need to introduce better tracking to draw any conclusions on how good they actually work. Claudio will surely have to say more about that in a future post.)
Current ideas:
#1
Give it a little more room to breathe
Update the wording, state how a feature can directly benefit the photographer
Use different emojis to keep the “playfulness” but giving it more variety
I was asked by Marc about how our settings work. Well, his original question was if we use React, but since we don’t and since I have this new blog here, I thought I just might try to give a very basic overview of how we implemented it. Maybe this is helpful to someone.
We define all of our settings using one big $settings array.
Today I am working on our static, in-plugin banner, we are currently displaying at the side of the settings page. I am in the process of changing it to an inline, “context aware” banner, which will contain much more relevant (and helpful) information.
Previously:
New:
The goal is to raise the awareness of how Pro can help the photographer in the context they are right now.