• Star Rating Update

    by

    A couple of weeks ago I shared a post showing the early stages of our star rating & filter implementation.

    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!

  • WP.org Guideline Violation 😱

    by

    Not an email you want to get on a Saturday:

    Turns out, when we refactored our settings, we changed the “Show picu love” setting to “on” by default. The WordPress.org guidelines however state, that “Plugins may not embed external links or credits on the public site without explicitly asking the user’s permission“.

    Fortunately – thanks to how picu settings work – it was a very quick and easy fix:

  • Star Rating and Filtering

    by

    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.

  • Close a Collection From the Approval Email

    by

    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:

    Screenshot of the approval email to the photographer, which contains an additional button at the bottom with the option to close the respective collection with one click

    The button will be part of the picu Pro 1.4.8 release.

  • Exclude Custom Post Type From Yoast

    by

    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' );
  • Individual Image Comments Now Have a Date

    by

    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.

  • Selection Goal Alert

    by

    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.

  • picu E-commerce – Phase 1

    by

    About a month ago, we announced that we will be working on adding e-commerce functionalities to picu in some form or another, and created a quick survey to learn more about how our customers would actually want to use this in the real world.

    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.

  • UTM Tracking Parameters

    by

    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.

    If you don’t know already what UTM parameters are, you can find an introduction in Google’s own Analytics Help Center to get you started.

    Setting some Goals

    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.

    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 parameterDescription
    utm_sourcepicu_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_mediumpro_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 parameterDescription
    utm_sourceWhere 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_mediumWe 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_campaignA 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_termThe screen this link was placed on in the plugin, like:

    screen_edit-collection – edit screen of our collections
    screen_picu-settings – our picu settings screen
    utm_content

    (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!

  • Improving “+ Add Client”

    by

    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.)

  • E-Commerce Survey

    by

    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.

  • Email required setting update

    by

    We had another discussion about the email required setting, see my last update about this issue.

    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:

  • Email required or optional?

    by

    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 previous registration 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.

  • Pro banner

    by

    We still use this static banner in a couple of places and from the feedback we got, we should definitely make it more concise and to the point. So…

    Previous:

    I updated the wording, and also made two versions, one with a light background color, so it might fit in better with our other, new banners.

    Dark:

    Light:

    • I figured the logo is not really needed and takes way to much space
    • Turned the text into a list and it is much more readable/scannable now
    • I still like to keep the social proof, and the stars are a nice eye-catcher

    I’ll let them sit for a bit, before making a decision.

    Update: And yes, there is a typo! Glad to have Claudio, who will surely catch those, before we ship the banners!

  • Goals for our new website

    by

    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:

    1. Modern, professional & friendly look:
      The old site feels more and more out of date and even a little unprofessional in some places.
    2. 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).
    3. 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.
    4. 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
    • Add the Pro icon we already use in the new settings banners

    #2

    • Add the same background and link color, as in the settings

    I think I am leaning towards #1. You?


    Update:

    The improved wording and new emojis:

    Still a work in progress…

  • How picu settings work

    by

    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.

    We can add new settings pages like this:

    $settings['general'] = [
        'title' => __( 'General', 'picu' ),
        'description' => __( 'General picu settings.', 'picu' ),
        'icon' => '<svg>…</svg>',
        'priority' => 1
    ];

    We can add individual settings like this:

    $settings['general']['settings'] => [
        'random_slugs' => [
        'type' => 'checkbox',
        'label' => __( 'Use random URLs for picu collections', 'picu' ),
        'description' => __( 'Disable, to use the WordPress default, generating the slug from the title.', 'picu' ),
        'default' => 'on'
    ];

    This is what it looks like in the WordPress Admin:

    There is a filter in place, which we use add settings from our Pro plugin. (Other developers could easily add their own settings as well, btw.)

    We iterate through this array to register all of the submenu pages and individual settings.

    We also have a couple of helper functions in place, which render basic setting types, such as checkboxes and text fields.

    But it is also possible to use a custom function for more complex settings by using the type of html and then adding the callback function via output:

    $settings['design-appearance']['settings'] => [
        'theme' => [
            'type' => 'html',
            'output' => 'picu_settings_theme',
            'label' => __( 'Theme', 'picu' ),
            'default' => 'dark'
        ]
    ];

    This is what the theme settings looks like:

    What I love most about this system is how easy it is to add new settings.

  • Shimmer effect

    by

    Not sure this will stay in, but I think this is a fun little effect, which adds a tiny eye-catcher to the Pro icon:

    It has more pause in between the effect in the actual implementation, than the gif above.

    Created entirely with CSS:

    .picu-pro-box__icon {
        …
        background: linear-gradient(-45deg, #027791 40%, #f2fafb 50%, #027791 60%);
        background-size: 300%;
        background-position-x: 100%;
        animation: shimmer 5s infinite linear;
        animation-delay: 3s;
    }
    
    @keyframes shimmer {
        12%, 100% {
            background-position-x: 0%
        }
        0% {}
        10% {}
    }
  • Today’s banner drafts

    by

    And these are all the different settings banners, I came up with today. Final wording and images tbd, of course.

    General:

    Design:

    Email:

    Security:

  • Improving in-plugin banners

    by

    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.

    🙌 Thanks Matt, for the input on this!

  • Hello world!

    by

    Welcome to the picu Dev Log.