WordPress.org

Make WordPress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 8:04 pm on April 29, 2016 Permalink |
    Tags:   

    Plugin Directory v3 Chat Summary 

    This is a summary of the Plugin Directory chat from April 27. (Slack log)

    Attendees: @ipstenu, @matt, @obenland, @clorith, @dd32, @pento, @tellyworth

    Topics:

    • Tagging system
      @matt encouraged the participants to figure out a tagging system that gives people a better understanding what’s behind the installation of a plugin. Something along the lines of a Free/Light/Pro classification, that illustrates the difference between (for example) Vaultpress (have to pay), Akismet (should pay if large), and Jetpack (no pay). This could be separate from the proposed 3-tag-limit and be based on an honor system starting out.
    • Determine what it means if a plugin is truly published
      After a detailed discussion about possible solutions and their repercussions around this topic, participants came to the conclusion that plugins should be approved, which triggers approval email and the creation of the SVN repo, but need an initial commit, to be switched to publish and actually show up in the directory. The goal is to ensure plugin authors are at least familiar enough with SVN to make a commit, to reduce support burden after mass emails to plugin authors that ask them to update in preparation of a major release.
    • Tickets for M2
      After committing the updates to reflect the changes decided on above, #1570 should be ready to go and considered fixed. @dd32 already fixed #1575, and @tellywoth and @pento anticipate #1574 and #1614 respecitvely to be finished by next week. Dion has started thinking about #1579 and has a shortlist of items containing Favorites, Contributors, Zips, Screenshots, and Stats pages. @obenland will look at the remaining ticket #1572. @mapk will be working on design mockups for the new front-end, and @ocen90 offered post-meeting to be available for any translation-related questions @tellyworth might have.

    The next meeting is on Thursday May 5, 00:00 UTC.

     
    • Ionut Neagu 5:18 pm on April 30, 2016 Permalink | Log in to Reply

      A tagging system it would be awesome, however I would find helpful to filter the free plugin where you are the product vs the free plugins which are just, free.

      For example I would prefer a lite/pro plugin over a free plugin which show me lots of ads, ask mandatory for my email, or add promotional stuff in the dashboard. Otherwise we may end up with the same issue that we have now :).

    • dartiss 6:53 am on May 1, 2016 Permalink | Log in to Reply

      I love the tag idea. Could I also suggest maybe having some way of indicating minimum PHP level? Of course, this may be a slippery slope as to what other software levels we should be highlighting but I, at least, think this would be a sensible addition.

  • Konstantin Obenland 8:52 pm on April 27, 2016 Permalink |
    Tags:   

    Weekly Plugin Directory v3 Chat 

    I’ve not been very good in making sure there’s a weekly chat for the work on the new Plugin Directory. No more! With a new and improved meeting time of Thursday, 00:00 UTC I think we should be set for regular updates going forward.

    Today’s agenda:

     
  • Mark Uraine 7:52 pm on April 18, 2016 Permalink |
    Tags: ,   

    Final Mockups for ‘Get WordPress’ 

    Working on this project has been a fun and creative journey and both @hugobaeta and I have made some great breakthroughs on the design direction for WordPress.org. Below are the final round of mockups (text still subject to change).

    (Want background on this post? Check out the IA post, followed by the initial mockups.)

    ‘Get WordPress’ landing page (located at /get/)

    Get WordPress - Mobile View

    Mobile

    Get WordPress - Desktop

    Desktop

    ‘Get WordPress’ subpage
    Mobile - Closed Nav

    Mobile – Closed Nav

    Mobile - Open Nav

    Mobile – Open Nav

    Desktop

    Desktop

     
    • Scott Winterroth 7:58 pm on April 18, 2016 Permalink | Log in to Reply

      These look awesome! Great work! One little thing, most of my students don’t realize at the beginning that WordPress is something that is installed on a web server, not to be installed on a personal computer. I might suggest putting a simple line of text indicating this.

    • Pippin Williamson 7:59 pm on April 18, 2016 Permalink | Log in to Reply

      I love these.

    • Thomas Townsend 8:06 pm on April 18, 2016 Permalink | Log in to Reply

      Wow these look fantastic, sure hope the copy for “WordPress Hosting” is expanded…

    • Aaron Jorbin 9:06 pm on April 18, 2016 Permalink | Log in to Reply

      Love the direction this going. A couple of things I initially notice:

      On mobile, Downloading seems like an odd Call To Action along with the decision to eliminate the requirements. My assumption is people looking at that page are in an explanatory phase. Maybe a CTA of “Remind yourself” with the ability to email themselves information?

      We should likely scrub all references to SVN as WordPress as core has been version control agnostic for the vast majority of people for a while now.

      I absolutely ❤️ that the mobile apps are at the top on the mobile view.

      For the requirements, do you think it might make sense to make it clear that these are things for a server and not for installing WordPress on your local computer?

      I’m not sure I love the idea of highlighting specific hosts on the download page rather than leading them to a dedicated hosting page.

    • Rene Hermenau 9:06 am on April 19, 2016 Permalink | Log in to Reply

      Beautiful, clean and modern – Love it!

      I suggest a slightly changed text for RECOMMENDED SECURITY: http://take.ms/tO18x
      The average user has no clue what that means and has no permission to do it.

      (The pro user who is installing php and server applications on his own is likely already aware of this and acts on his own responsibility)

      When we assume that most hacked sites are the ones running on cheap and less secure webspace we have to use our 25% market position to make sure that providers take more care about security standards.

      The easiest way to “force” hosting agencies for better security implementations is to make user more aware of choosing a hosting service of better quality.

      1. Remove “NOT REQUIRED”. That makes the statement less powerful.
      If we emphasize that security tasks are not required, people will less care about it.
      RECOMMEND already includes that it is not required.

      I suggest something like:

      RECOMMENDED FOR BETTER SECURITY

      or

      HIGHLY RECOMMENDED

      Use only reliable and well rated hosting providers
      who are promising to take care about your site’s security.

      We have summarized a collection of higly recommended security standards:
      https://codex.wordpress.org/Hardening_WordPress

      Ask your potential host if they ensure the security of your account
      following these standards or check out our recommended hosts.

      Btw. (Dont want to be a smart ass but that typo catched my eyes: http://take.ms/x5Ws7)

    • Julien 9:18 am on April 19, 2016 Permalink | Log in to Reply

      These looks really nice but I find that add some pictures of the software will tease it more. For me, there is too much text and for new comers, they can’t see how the software looks like and what it does exactly. Meaning they have to go through a full installation to see what WordPress is and do.
      Also I find the word “software” too large and perhaps not appropriate. Like Scott Winterroth mentioned above, it’s not clear it is a web “software”, and not “native” OS software.
      Finally I found the content to be mostly oriented to people who generally already know WordPress and that this page will not convince newcomers to start working and develop with WordPress. Perhaps add some features normally only showed in the wordpress.com website.

    • chrishoward 12:26 pm on April 19, 2016 Permalink | Log in to Reply

      Look great!

      As noted by Aaron, download link on mobile is pointless. However, you could have an “Email download link”.

      Also, I think the app store buttons should be in a row, not a column. Reduces a smidge of unnecessary scrolling.

      And, on mobile and desktop, I feel like the hosting should have centred headings and links, and justify the body. It just looks a little out of whack because of the centering of the elements above and below.

  • Mark Uraine 12:24 am on April 2, 2016 Permalink |
    Tags: , ,   

    Plugin Directory Design Direction 

    Earlier this week, a few of us met to discuss the design direction of the Plugin Directory. Myself, @michael-arestad, @hugobaeta, @melchoyce, @helen, and @samuelsidler looked at the current directory and challenged ourselves to look at it from a fresh perspective, exploring flows, UI, and content. The overall goal was to set a direction for the design.

    After a couple days of whiteboard drawings, we’re a lot closer and I wanted to share some explorations with you.

    Please note that the below explorations are wireframes and heavily subject to change. They’re only meant to give you an idea of the direction we’re looking at.

    We discussed three views:

    1. The landing page (wordpress.org/plugins/)
    2. The Search results view
    3. The Single Plugin View
    Plugin Landingpage

    Plugins Landing page

    Plugins Search Results

    Plugins Search Results

    Plugins Single View

    Plugins Single View

    Some pictures of our whiteboards

    On each view, here are some thoughts on the direction.

    Plugins Landing page (/plugins/)

    • The title block is much longer, with a more prominent search field at the top. Search is the primary action in the directory and we’re working to improve it.
    • The addition of a slider for featured plugins… yes that’s not misspelled, I wrote “slider”. 😉
    • Sectioned plugin blocks around various “filters” of plugins. As a sample, we used popular, trending, and beta, but these could be anything in the future.
    • The “Developer Center” that currently exists becomes a small “Plugin Authors” callout at the bottom of the page since it’s not frequently used. We’d add other blocks (like the ones show) where relevant.

    Plugins Search Results

    • Search results maintain a similar style as the landing page.
    • Search field remains prominent in the title block.
    • In fact, when searching from the landing page, everything under the search box is replaced with results.

    Plugins Single View

    • Maintain a large plugin banner at top of the view.
    • The plugin name will no longer be over the banner.
    • Below the banner, we show the name of the plugin, author, and a Download button.
    • The Translation Information displayed will note if a plugin is available in your language or, if not, allow you to click and see it on your localized site with a callout to begin a translation.
    • Tabs are removed. Instead, content blocks act as accordions on the page, revealing information when a visitor clicks to know more. The main column holds the following information:
      • Description
      • Changelog
      • Screenshots in the form of a gallery/slider (to be explored).
      • FAQs – We debated this section a bit, but FAQs are still quite important, when they exist. Ideally, these could be added in the plugin author dashboard instead of the readme so the format is more consistent. If that happened, we could show a list of questions with accordion-like answers when clicked.
      • Reviews – Becomes a section on this view where you can click to see more reviews.
      • “Contribute” is the new “Developers” section. Here we’d show relevant developer information, contributors, a donate button, and all available translations. As we experiment, this may become another view similar to Reviews where you click to see more detailed information.
    • Meanwhile, the sidebar remains, but becomes more condensed. In it, we show:
      • Ratings – a break down by rating.
      • Support – a “widget” that shows relevant support information and allows the visitor to click to enter the support forum.
      • Active Installs
      • Last Updated
      • Category
      • “Designed to work with” option, if relevant.

    Overall, we worked hard to keep the most relevant information for visitors as information that’s important to plugin authors moves to the plugin admin dashboard.

    Thoughts?

    As a reminder these are wireframes to give you a general idea of the direction we’re heading.

    What do you think about the direction? Are there things you think should be removed? Things that should be added to the main views? Leave your feedback in the comments.

     
    • Konstantin Obenland 3:29 am on April 2, 2016 Permalink | Log in to Reply

      A slider? Gasp!

      I’m not a big fan of the centered title/tagline honestly. I also wonder if the search field will be overshadowed by the visually prominent slider below. For the single view I was hoping you’d been more daring in terms of the information that is shown there. Did you talk about the banner size and how it relates to the content width there?

      Imagine a list of everything else that makes up these wireframes, which I really like! 🙂 Especially the homepage looks neat. Good job everyone!

      • Mark Uraine 5:55 pm on April 4, 2016 Permalink | Log in to Reply

        The centered title/tagline is a design pattern we’re going to be using across the site. We’ll definitely have to make sure the search stands out and isn’t overshadowed by the slider.

        We didn’t talk about banner size. I know there’s probably a concern there b/c it will be displayed probably larger than how it is now.

    • M Asif Rahman 3:57 am on April 2, 2016 Permalink | Log in to Reply

      In Plugin Single View we are going to hide more content from description?
      What if we have video in description? Could we add video in screenshot or somewhere dedicately?

      • Mark Uraine 5:56 pm on April 4, 2016 Permalink | Log in to Reply

        I imagine the video would be included with the screenshots section. We didn’t discuss video much, and I’m not sure about the limitations (if there are any), so I’ll have to look into that.

    • George Florea Banus 6:07 am on April 2, 2016 Permalink | Log in to Reply

      What ever design you go for I want to be able to order plugins by installs, latest, last updated, rating etc.
      Also add a lightbox for the screenshots, many don’t even open in the browser but are downloaded.

    • Ulrich 9:07 am on April 2, 2016 Permalink | Log in to Reply

      This sounds good. I wonder if the order of the information on a single plugin is correct. I feel changelogs are not so important to people searching a new plugin to use. Screenshots and reviews would be more useful.

      It may be good to have some links link the content sections as landing on the page the user may not realize that there is more content lower down. It is a bit early but the section titles should be linkable so that it easier to point users to the correct section.

      The available translations would be more useful in the sidebar as I can check is the plugin supports my language in one glance.

      Have you thought about what happens when a plugin does not have a banner or icon? Some plugins have randomly generated icons which do not look that pretty and do not provide any use. Normally the banner does not contain useful information but gives a bit of colour to the page and helps with brand recognition. What if we made the banner to full width taking away a bit of the focus? Here is an example. https://wpzoo.ch/en/2016/02/hello-world/

      I am not sure if this is in the scope of the project. “Featured” plugins have not been updated in quite some time. For me featured plugins are only worthwhile when it is a curated list that is updated regularly with new plugins. The featured themes are random themes that have been updated in the last two year. If we do something like that for the plugins then we may just rename the section to random plugins.

      • Mark Uraine 6:02 pm on April 4, 2016 Permalink | Log in to Reply

        Good point about the Changelogs – prolly not that beneficial to new users searching for plugins.
        Links to specific sections is do-able.
        The translations bar at the top is a design pattern we’re exploring with some new site designs.
        We spent some time talking about banners/icons and the absence of them. Still working through ideas.
        Featured plugins would be good to curate, I agree.

    • Marius (Clorith) 11:22 am on April 2, 2016 Permalink | Log in to Reply

      If we’re moving featured ones into a slider, we may as well do away with the featured ones altogether or just show “feature of the day” and a single plugin. Most people won’t stick around to watch it slide through options, and it hides anything not in the first slide more than shows them off.

      @grapplerulrich makes a very valid point about the list having been stagnant for a (to me) unknown period of time, but I don’t remember the last time it didn’t look like it does now, which plays well into my comment about “maybe just remove it” 🙂

      Little bit worried that the single view is information overload, sure you hide a lot of content behind read more expanders, but it’s still a lot of different contents in a single view for many users and may be information overload all at once.

      Other than that I do like the direction this is going!

    • Anton Timmermans 12:53 pm on April 2, 2016 Permalink | Log in to Reply

      I think this is a great way to go, not a big fan of the slider.

    • J.D. Grimes 1:06 pm on April 2, 2016 Permalink | Log in to Reply

      In regard to the single plugin view:

      I don’t think displaying the changelog prominently has any real benefit for most users. I would either move it lower in the page, or else maybe better to leave it where it is but hide the content entirely so the user has to click the “read more” (or maybe “show”, in that case) link to see it.

      I’m also not sure about displaying the plugin icon in addition to the banner, it will probably be redundant, or as @grapplerulrich says, will just be auto-generated.

      I also think that jump-links to each of the sections as @grapplerulrich suggested might be a good idea.

      And one more note, though you are likely aware of this, plugins can add their own custom sections to the readme, and these are currently displayed as custom tabs. I don’t think you’ve addressed what will happen to them?

      All in all I like the direction you are taking this.

      • Mark Uraine 6:05 pm on April 4, 2016 Permalink | Log in to Reply

        In regards to the custom sections on the README, I’m not sure this is completely resolved. They most likely will either become their own section on the page toward the bottom, or be eliminated altogether. Do you have some thoughts?

    • Samuel Wood (Otto) 2:44 pm on April 2, 2016 Permalink | Log in to Reply

      “The plugin name will no longer be over the banner.”

      People have designed their banners around the plugin name being positioned over it like that. If we change this, then those banners will need to be altered as well, and people will start doing dumb things like including the plugin name in the image themselves. This is thus a bad choice for internationalization and non-English languages.

      • Mark Uraine 6:08 pm on April 4, 2016 Permalink | Log in to Reply

        By removing the name from overlapping the image, it will require people to edit their witty designs, but I’m not so sure it will encourage them to add the name themselves. I believe we’ll have a design guide for banners and icons where we’ll be explicit about best practices.

    • Achin 3:39 pm on April 2, 2016 Permalink | Log in to Reply

      A quick thought. How about having Accordions for the sections “Popular” , “Trending” etc? This would help save time scrolling through these categories.

    • David Gewirtz 4:39 pm on April 2, 2016 Permalink | Log in to Reply

      I would strongly recommend moving away from screenshots and, instead, highlighting videos. The screenshots are often difficult to see on long dashboard pages, but video tutorials are active and engaging. Also, support is probably considerably more important than translations and should be very visible and very easy to get to.

      I use the wp.org support forums as my primary mechanism of support and they are VERY active. But I’d love a way to have more control of posts (like when someone posts in a thread that’s unconnected to its purpose) and a way of reaching out to my users to warn them when something big is about to happen (like PayPal’s change to a new format coming in September).

      It would also be great if there were a way to externally access and aggregate the forums in a support tool, or see all my new support requests across all my plugins at one place.

      Basically, please think about this not only from the plugin consumer’s point of view in choosing new plugins, but also from the plugin user’s and developer’s for ongoing use and flow. I’ve found that the wp.org support section for my plugins becomes the community hub for my users, and I’d like to be able to optimize it more to involve and support that community. Otherwise, I’ve been thinking strongly of redirecting all support questions to a forum on my site, but that kind of defeats the purpose of keeping everyone involved on wp.org.

      In any case, thanks for your great work.
      –David

    • Mark Howells-Mead 9:16 pm on April 2, 2016 Permalink | Log in to Reply

      This does sound good! I would query what role the re-design and improved UX will bring to those browsing the plugin directory via the backend, as this is probably the point from which a lot of people will access it.

      I agree with other comments, that consideration should be made for plugins without icons and without banner images. Many plugins don’t provide functionality which can be shown visually and a large area dedicated to visual decoration for every plugin is superfluous in many instances.

      As to a slider, I also agree with other comments: it’s a well-known but outdated means of showing information in a clear and simple overview. A small cascade of teasers in three rows with 1, then 2, then 3 plugins would be more quickly scanned; also proving immediate visibility to plugins in latter positions and making the view much more easily digestible.

      And for the individual sections on the single view: I agree that an accordion would be useful. A view showing the summary information, with the option for the additional sections to be expanded. (Remembering the open/closed state of each section between page requests, so that people comparing functionality or change history between various plugins don’t have to keep opening each section anew on every page request.)

    • Mark Howells-Mead 9:19 pm on April 2, 2016 Permalink | Log in to Reply

      An additional note from a usability point of view: an improved filter and the ability to sort search results would be a long-overdue improvement. For example, to run a search like https://wordpress.org/plugins/search.php?q=honeypot and then sort the results to show the most recently updated plugins first.

      • Mark Uraine 6:14 pm on April 4, 2016 Permalink | Log in to Reply

        Yes, yes and yes. I’m definitely pushing for a more filter-able search ability. We will be updating the search field for sure.

    • Ahmad Awais 12:49 pm on April 4, 2016 Permalink | Log in to Reply

      While I like the wireframes there are certain concerns.

      Sliders? Ehm… ermm…

      Reviews on plugin landing page? Means if someone writes a wrong bad review (E.g. Last time someone gave my plugin 1 star and a very bad review just coz my plugin ain’t compatible with VisualComposer, turns out it was the issue with VisualComposer as its code is a big mess with no standard whatsoever, and I never claimed my plugin to be compatible with that plugin) that would drive plugin downloads and SEO down.

    • Brad Touesnard 5:44 pm on April 9, 2016 Permalink | Log in to Reply

      Would getting rid of the tabs also mean losing the individual pages for each tab? If so, that could have a serious impact on each plugin’s footprint in Google search results.

    • Mickey Kay 5:12 pm on April 12, 2016 Permalink | Log in to Reply

      First of all, fantastic work. Not only are y’all taking on a large task that’s going to make things better for many people, you’re making it look good! Woot!

      Secondly, a few thoughts/suggestions. . .

      1. Support search
      If at all possible, I would love to see the new individual plugin screen include the ability to search support threads. This will make it easier for authors to parse their tickets, but more importantly, it will make it easier for end-users to check to see if their question/issue has already been addressed before filing a new ticket.

      2. Use of space
      Right now, there’s a ton of content in the single plugin view’s main content area, and almost nothing in the sidebar. This means that 1/5 of our precious horizontal space isn’t used at all for the vast majority of page, once users have scrolled down a couple hundred pixels. Consider this alongside the fact that you’re already looking at consolidating what used to be tabbed content into one long single content area, and I think we should do everything we can to use space/scroll as economically as possible. My suggestion would be to either a) move some content into the sidebar, or b) (oh boy. . .) ditch the sidebar entirely. Other related ideas in #3 below.

      3. Read more links
      I’m not fundamentally opposed to this user experience choice, however it’s definitely not my favorite. For one, it causes a somewhat jarring experience. These accordion style links cause what feels to me like a pretty jarring scroll, making it pretty easy to lose track of where one was originally reading (especially so when collapsing the accordions). In my mind, if you’re choosing between tabs and read more accordion expanders to consolidate text, tabs would always be my top choice – perhaps just switching from a full page reload when a new tab is clicked to a simple jQuery tab toggle instead.

      4. Order priority
      Folks have spoken as to what is top priority for them, and I would really like to see the ordering of content match this feedback. As mentioned, change logs are pretty irrelevant to most end users, and as such I would relegate them as lower priority. Another thought is to try to group content into end-user vs developer groups as much as possible. Change logs, svn links, etc all matter to developers, but probably not at all to end users. Additionally, I would love to see us use our sidebar (aka secondary) area for content that is indeed “secondary”. Translation info, contributors, etc all belong here in my mind.

      Keep up the great work! Thanks y’all!!!

  • Hugo Baeta 6:58 pm on March 30, 2016 Permalink |
    Tags: , research, UX   

    WordPress.org UX Research 

    Over the years, with a lot of resources being put into core, the WordPress.org network of sites has been interated upon without much structural or art direction. As we take on efforts of documenting and creating more polished and art directed design foundations for the WordPress project as a whole, the .org sites need to get some love as well.

    The first step is understanding what can be improved, what the real pain points are. So I conducted a survey a few months ago to better understand how contributors and other community members interact with WordPress.org sites. The survey was sent to a select group of people – project leads, team reps, highly active community members, etc. The sampling was small (32 participants) and so the survey had a lot of open-ended questions, allowing the participants to write their thoughts freely, revealing the biggest pain-points. The survey was divided into sections for better understanding of the usage of the several parts of the website.

    This survey will help us get a better idea of the direction we need to go on a long-term plan to make improvements to WordPress.org, building a more solid and thought-out foundation so the community can grow and thrive for years to come.

    The survey was anonymous (which I personally found important in order to encourage more honest feedback), so I’m including here some of the most constructive feedback provided.

    This is quite a large post, with the survey results and relevant comments – 15 sections with a total of 55 questions. So brace yourself and continue at your own risk 😛

    (More …)

     
    • Mark Uraine 7:16 pm on March 30, 2016 Permalink | Log in to Reply

      This is my new favorite post! Excellent work and very telling. Thanks @hugobaeta.

    • Ulrich 7:43 pm on March 30, 2016 Permalink | Log in to Reply

      It is nice to see steps being taken to improve 🙂

    • KirsiD 9:33 pm on March 30, 2016 Permalink | Log in to Reply

      Thank you for sharing this! As a UXD wanting to get more into front end dev, I’d love to contribute. I put it off recently because my experiences mirror this research, I just don’t know where to start. I’ve gotten lost in the whirlwind of information. Great research!

    • Eusebiu Oprinoiu 11:16 pm on March 31, 2016 Permalink | Log in to Reply

      I am so glad to see a redesign is coming and that the UX is given the priority it deserves.
      As I read the answers I felt the struggles of each respondent and I really hope at least some of the highlighted issues will be solved in the near future.

  • Mark Uraine 11:59 pm on March 23, 2016 Permalink |
    Tags: ,   

    Get WordPress Mockups 

    With the desire to improve the path for how people “get WordPress”, I proposed some Information Architecture ideas. Today, I’ve got a mockup to communicate these concepts.

    First, I wanted to bring the different ways in which someone can ‘get WordPress’ into one single page that would communicate their relationship with one another effectively and clearly. Second, any buttons that say “Download WordPress” should actually download the software, and not link to another page.

    These two points are addressed with the following mockup. The mockup combines downloading WordPress, downloading the mobile apps, and hosting into one page, with sub-pages for each. Combining these options provides a well-rounded view of how someone might go about “getting” WordPress – whether by downloading the software and setting it up themselves, having a hosting provider take care of it, or obtaining the mobile apps. Each section links to sub-pages that delve into more detail.

    The mockup also slims down the navigation of this section of WordPress.org and unifies related content.

    /get page mockup

    /get page mockup

    View full size mockups

    Design Decisions

    The mockup above has some explicit designs that are worth noting:

    • Button styles are the same as the one in core.
    • The title bar on this landing page has a new design, unlike others throughout WordPress.org (but somewhat similar to make.wordpress.org).
    • Dashicons have been used on the page, when relevant.
    • The typographic scale has been refined and Open Sans has been embraced.

    This mockup is a view into the design direction for WordPress.org, so please chime in with your comments. I’d love to hear your thoughts.

    (With great help from @hugobaeta.)

     
    • jesmion 2:42 am on March 24, 2016 Permalink | Log in to Reply

      Actually, these works need to be urgently done, because there is unusual discovery that a new subscriber with a mobile device couldnt signup with wordpress.org due to recaptcha failure, and the system continue requesting for a recaptcha but nothing seeing visible about it

    • Ulrich 7:39 am on March 24, 2016 Permalink | Log in to Reply

      This is a really nice design. I am not sure how much of the content is fixed. I feel it is a bit unfair to only have bluehost on the main page and the rest on a secondary page. It is ok if the host changes once a day or on every page load. I wonder how important is it for the “get listed” to be on the main page as it is only of interest to hosting companies and not the end user.

      • Samuel Sidler 4:24 pm on March 24, 2016 Permalink | Log in to Reply

        It’s not clear from the mockups and I completely forgot about it when helping @mapk with this post, but the intention is to rotate out two hosts on this page every time its refreshed. However, right now, we only have one host on the Hosting page, so we’ll fill that box with a “Get Listed” section. That’s meant to be temporary however.

    • Lara Littlefield 2:46 pm on March 24, 2016 Permalink | Log in to Reply

      I think the focus on “Get” is great, mimicking the great call to action the Apple iOS app store now uses for free apps instead of “Download” or “Free.” These mocks present a much more compelling and concise home front for WordPress, the OSS, than the current version. I think the transition to sans-serifs including headers, in particular, makes this *feel* like a 2016 UX.

      However, there is significant attention paid to WordPress.com here, which currently does not exist on the .org site. Why is this renewed focus being sent to Automattic? I thought venture capital $$ was independent of WordPress.org? That is the same feeling I get with the entire hosting section on these front page mocks, as Ulrich pointed out above. Has the mission of the Foundation changed? Also, where are the trust marks for the largest brands or enterprises that use WordPress? Or any indication of the templating or plugin system? What about VIP? I’m curious as to the focus on hosting in these mocks vs. the actual code of WordPress. Thank you for your hard work!

      • Samuel Sidler 4:29 pm on March 24, 2016 Permalink | Log in to Reply

        To be clear, this page is not meant to replace the homepage, but rather the Download WordPress page. WordPress.com has been listed on that page for years and years. Updating the style of this page gives WordPress.com a “bigger” focus than it has currently, perhaps, but that’s also to be expected as we move away from a text-heavy page.

    • Michael Arestad 2:59 pm on March 24, 2016 Permalink | Log in to Reply

      Can you post some full size mockups please? It’s hard to get a sense of scale from these.

    • purzlbaum 3:00 pm on March 24, 2016 Permalink | Log in to Reply

      Just wondering about the download button (not the app strore download button) on mobile/tablet. I’ve never downloaded WordPress on a phone or tablet.

      I think you should do the same thing as on desktop. Put the focus on mobile/tablet of downloading the apps and on desktop on download the WordPress zip file.

      • Mark Uraine 7:04 pm on March 24, 2016 Permalink | Log in to Reply

        This is interesting. I gave the apps more prominence on mobile/tablet by positioning it at the top. But maybe the scale and blue-ness of the download button still gives it too much importance? I think the download button is still viable to have there on mobile/tablet because people have devices that can actually download these files. I would agree that it’s probably not nearly as much as downloads occur on desktops, but I think the availability should still be there, yea?

    • Konstantin Obenland 5:22 pm on March 24, 2016 Permalink | Log in to Reply

      Does the content order change based on user agent or window width?

      Also, let’s remember to make that “WordPress is also available in %s” part translatable when we get into implementing it 😉

      • Mark Uraine 6:55 pm on March 24, 2016 Permalink | Log in to Reply

        Content structure will change based on window width. Content itself (ie. the iOS button as opposed to the Google Play button) will change on user agent.

      • Samuel Sidler 7:44 pm on March 24, 2016 Permalink | Log in to Reply

        We can’t easily make it translatable, sadly. It can list multiple languages depending on locale. For example, in Canada, we might say “WordPress is also available in Canadian English and Français Canadien.”

    • Mel Choyce 7:30 pm on March 24, 2016 Permalink | Log in to Reply

      Thanks for posting the larger mocks!

      I think structurally the page is looking pretty good. I had some questions but it appears @samuelsidler has already answered them. 🙂

      Some small details I noticed:

      • I know you’re working off a typographic scale, but I’m not sure what you’re using is actually working in-context, especially with the width of the different blocks of content. There’s a lot of super-short, ragged lines (Requirements, the three Hosting blocks) that could be smoothed out by reducing the font size or widening those columns, where possible.
      • “WordPress is also available…” is not centered within its container (looks like it’s 2px too low)
      • I think the line-height on “Choosing a host…” can go down a bit, or the text can move away from the header by about 3-5px more to make it feel more balanced (super minor nitpick)
      • I’d move the links below each hosting block down 5-10px
      • “See all our recommended hosts” is centered but optically feels off-center because of the three columns above it. Maybe try adding a short divider between those three sections and the link? Thinking about it, a short divider could also work to improve the visual balance between Release notifications and the “Discover” link beneath it
      • Do the Apple Store/Google Play store offer larger badges? The headers are super big and then the buttons are super small and it feels a little wonky
      • I’d left-align all the text on the smartphone-sized mocks, the centered text on such a small screen feels very unbalanced
      • Mark Uraine 8:30 pm on March 24, 2016 Permalink | Log in to Reply

        Good point about the typographic scale. Right now the body text size is 21px and is a bit large for the smaller columns. Do you think having a smaller body text size is the way to go, or just reducing the size for the narrower columns?

        I didn’t notice any larger store badges offered, but I’ll double check.

        The other feedback is great too… and straightforward. I’ll explore those solutions. 🙂

        • Mel Choyce 3:34 pm on March 25, 2016 Permalink | Log in to Reply

          Not sure — I’d try out 19px and 20px to see if they fit a bit better for everything. If not, you could probably just reduce the size for narrower columns.

    • Tammie 10:09 pm on March 30, 2016 Permalink | Log in to Reply

      Thanks for the great work @mapk. It’s great to see this starting to get a focus. I am very excited considering the adaptive from start approach too.

      First up, I’ve got a few thoughts based purely on your mockups. I’m going to read the comments and add those thoughts based on that after. I want to give your mockups a chance to speak to me. Forgive any dupes in the comment as a result.

      Lets do each by device size too and start with mobile:

      • I would urge the removal on devices that can’t download, of the download option. It just has a horrible white screen and that’s no fun.
      • I do feel the page is a bit long on mobile. We can mitigate this with a ‘to top’ link (not something I always like but may be needed), but again it’s a lot of scrolling for less important information.
      • I would probably encourage a tighter typography scale and really reduce down on mobile a little bit. Same goes for visual space. You can remove a lot and still make it work.
      • I see you’re trying to not touch the header but I would really encourage at least adding context to the hamburger with a word and scaling the size along with logo.
      • At a glance in small screen it’s now hard to distinguish the search box. Maybe iterate on that a bit.

      Mid-range:

      • This actually out of all of them feels the most true to device which is nice.
      • Same comments about header though as this feels a lot of wasted space.
      • I feel the mid call to action section is less strong as it goes down. Maybe this will change if you remove download as probably again you can’t download.

      Desktop:

      • I like the two column and iterations on the sections. They make a lot of sense.
      • I like the humanising of ‘inspiration strikes anywhere, anytime’. I want that level of emotion to be in the other versions. It feels lacking in those which is a shame as it’s so powerful.
  • Konstantin Obenland 10:16 pm on March 18, 2016 Permalink |
    Tags:   

    With the time change in the US, we had to review the weekly plugin directory meeting time.
    Starting next week we’ll meet Thursday, 01:00. Some of the contributors will be traveling in April, meeting times then will be announced on a week by week basis, but should end up being Thursday, 07:00.

    [Edit]: Fixed the times.

     
    • Ipstenu (Mika Epstein) 12:04 pm on March 20, 2016 Permalink | Log in to Reply

      Both of those times are just not going to work for me at all.

      That’s midnight and six am pacific. So you’re going to have to post some recaps, guys.

      • Konstantin Obenland 4:53 pm on March 21, 2016 Permalink | Log in to Reply

        Looks like the script is not picking up my times correctly. It’s 1am UTC, so 6pm PT not midnight. I picked the times thinking of daylight savings time ending in Australia next week which makes it harder for @dd32 to attend at the current time.

  • Mark Uraine 10:37 pm on March 15, 2016 Permalink  

    Crosspost for Web Store Flows 

    Hi folks – this is a crosspost for Various Web Store Flow Explorations concerning the Plugin Directory.

    Please comment over there.

     
  • Mark Uraine 9:10 pm on March 1, 2016 Permalink |
    Tags: , information architecture,   

    Thinking about the Plugin Directory IA 

    Developing a new plugin directory gives us the opportunity to revisit its design and user experience. It’d be helpful here to start with the information architecture. To begin this process, it’s a good idea to look through the current IA. Here are some diagrams of the current IA.

    Current Information Architecture

    Current Overview IA

    Current Overview IA (/plugins)

    Current Plugin Detail IA (/plugins/[plugin-name])

    Current Plugin Detail IA (/plugins/[plugin-name])

    Current Plugin Developers IA

    Current Plugin Developers IA (/plugins/about)

    Items for Consideration

    Looking through the current information architecture, a few questions come up:

    1. We currently show a ton of information on the plugin detail page. What information is necessary when viewing a plugin detail page?
    2. “Developers” is used in two ways throughout the plugin directory: one provides developer information on the plugin detail page, the other links to plugins/about which gives information on how to develop/submit plugins to the directory. Is there a better way to phrase/display this information? Most of the latter content has moved to the Plugin Handbook. Is this page even necessary?
    3. We currently show a version history in two places: under “Developers” on the plugin detail page, but also when you click the “Changelog” tab. Can these be combined? Maybe show a version history that can expand (like an accordion) on click to show the fixes included in that version?
    4. “Installation” doesn’t contain useful information, for the most part, probably because “installation” is standard for all plugins. Should we remove this tab/information from the plugin detail page? How are plugin authors using this tab now? Should we rename it?
    5. There are several tabs that could be combined into the Description tab, including “FAQ”, “Other Notes”, and “Screenshots.” Is it worth combining these into one? If so, are there other changes we should make to allow a better flow of the information?
    6. Rating a plugin requires writing a review. Can we make this clearer by standardizing on a name? “Reviews” or “Rate and Review”, perhaps?
    7. Given the changes being discussed for tags, should we drop the Popular Tags page altogether in favor of a better homepage?

    Feedback

    We’re looking for feedback on the current IA as well as the questions above. If you have any opinions or ideas, comment below.

     
    • Samuel Wood (Otto) 9:15 pm on March 1, 2016 Permalink | Log in to Reply

      Changelogs and the change links on the Developers tabs are not the same. The Changelog tab contains changelog information from the plugin author in the readme.txt file. These should be user facing. The Developers tab shows commit information and links to past versions for download. These should not be combined as they are different sets of information intended for different audiences.

      If you want to hide something, the Developers Tab could be only shown to logged in users. That’s reasonable. But it needs to exist and be separate somewhere.

    • Samuel Wood (Otto) 9:16 pm on March 1, 2016 Permalink | Log in to Reply

      Installation can be made optional, and we should encourage plugin authors to only use that area in their readme.txt if they have meaningful information to convey, rather than the standard “find plugin, click install link”. This tab was more useful in the past (6+ years ago), not so much today, but there are cases where an author might have special install instructions.

    • Samuel Wood (Otto) 9:19 pm on March 1, 2016 Permalink | Log in to Reply

      For a shocking number of plugins the Description field is far too long and wordy already. Keeping FAQ separate is important, but it is already optional and a number of plugins leave it out. I have no objections to killing Other Notes.

      Screenshots I would prefer to keep separate and not directly integrate them into the main Description area, but perhaps it should be better integrated as a whole instead of being a separate tab/page just for them. Depends on the design.

      • Ipstenu (Mika Epstein) 9:37 pm on March 1, 2016 Permalink | Log in to Reply

        Seconded.

        Since we can’t really control design per-plugin, having screenshots be a separate page is more sustainable for plugins with a lot.

        Other Notes was a nice experiement that’s mostly been used to spam :/

    • Samuel Wood (Otto) 9:21 pm on March 1, 2016 Permalink | Log in to Reply

      Popular Tags should die, since we won’t have tags anymore. The categories and any other form of taxonomies we use should replace it instead.

    • daniyalahmedk 9:22 pm on March 1, 2016 Permalink | Log in to Reply

      I think on Plugin detail page, following information can be considerable.

      1. Live Demo link.
      2. I think require and compatible info can be combined.
      Requires: 3.0.1 or higher
      Compatible up to: 4.4.2
      3. Compatibility form can go under stats page.
      4. I think there is no need of Translations on plugin detail page.
      5. There could be recent reviews section on details page.
      6. “Donate to this plugin” can go above nearer to live demo link 😉
      7. I think there is no need to show complete “Ratings” just one row of stars.

    • Samuel Wood (Otto) 9:23 pm on March 1, 2016 Permalink | Log in to Reply

      The /plugins/about area will get a redo, with most of the links and descriptions and such pointing to the relevant sections of the handbook. We’ll probably do this as Static Pages in the new site, adjusting as we go. But most of the static links there will die/get redirected.

      • Mark Uraine 9:51 pm on March 1, 2016 Permalink | Log in to Reply

        I guess my question here is… Is the /plugins/about area even necessary if we have the Plugins Handbook? I’m not sure funneling people through a middle page to get to the Handbook is the best route, unless I’m missing something.

    • Drew Jaynes 10:43 pm on March 1, 2016 Permalink | Log in to Reply

      I notice the “Admin” tab is missing from the plugin details. As far as I know that only shows for plugin committers, but worth considering.

      I agree about dumping “Installation” and maybe even “Other Notes” and just replacing both with “Usage”. I also agree with the need to keep “FAQ” separate in the plugin detail view.

    • Mark Uraine 6:34 pm on March 2, 2016 Permalink | Log in to Reply

      I’ve updated the Plugin Detail diagram with the ‘Admin’ stuff.

    • Konstantin Obenland 6:04 pm on March 4, 2016 Permalink | Log in to Reply

      Given the changes being discussed for tags, should we drop the Popular Tags page altogether in favor of a better homepage?

      Yes, depending on what we decide to do with categories or tags, they should probably just be a part of the “filter bar” like in the theme directory.

    • FolioVision 5:51 am on March 10, 2016 Permalink | Log in to Reply

      I agree with Rene that the replacement name should be short and sweet. My suggestions would be “Getting Started” or “Setup”. And yes, we plugin developers should use the section. With a better name, hopefully we will.

      FAQ really must stay as the catchall (what was attempted with “Other Notes” which in the end is a sort of strange cousin of all of description, installation and FAQ).

    • Franz Josef Kaiser 1:24 am on March 16, 2016 Permalink | Log in to Reply

      Where is the link to GitHub (or Bitbucket)?

      When already in the process of redesigning, then things like source code view can be left off to a service that already this one pretty well. They also have a pretty good issue and pull request system in place with an UI that is usable. Every developer loves it (well, I am sure that Otto doesn’t) and it just works, gets out of the way and makes collaboration frictionless.

    • M Asif Rahman 2:19 am on March 16, 2016 Permalink | Log in to Reply

      One small request. Could we show date of release in changelog? We might need to restructure the changelog format. Right now some developer does that manually, I also do that. As date when a version got released in important in many time.

    • Mark Uraine 10:12 pm on March 18, 2016 Permalink | Log in to Reply

      While exploring thoughts on the Plugin Detail page, we currently show a lot of info in different tabs. Is this necessary? Can we combine it into a README file similar to how Github handles it (ONE page)? I know many write a lot of stuff for each of these tabs, but who really reads all of it? With a desire to make this more usable to users, shouldn’t some of this be limited?

      Right now it appears that there’s an agreement to possibly get rid of “Installation” (combine it into the “Description” or “FAQ”) and get rid of “Other Notes”.

      There’s definite interest for keeping the “Changelog”, “FAQ” and “Screenshots”.

      Another suggestion is to only show the “Developers” tab to users who are logged in?

      Is “Support” necessary as a tab, or can it just link over to another page without mimicking the Plugin Detail page?

      Can “Stats” be combined into another section or handled in the Admin? Are users really interested in all the different charts or mainly just in the number of downloads?

      So if we keep a tabbed approach, we’d have something like “Description”, “FAQ”, “Screenshots”, “Changelog”, “Stats”, “Support”, “Reviews”, “Developers”

      Still a lot of tabs. Is there a better solution?

    • Mickey Kay 5:53 am on March 22, 2016 Permalink | Log in to Reply

      Great post and responses – loving the conversation.

      As a plugin developer myself, I’d love to see a more utilitarian dashboard for developers that allows folks like me to more easily view our various projects. I lay out a lot of details in this recent post: http://mickeykay.me/2016/03/model-for-new-wordpress-plugin-directory/

  • Mark Uraine 8:20 pm on February 29, 2016 Permalink |
    Tags: download, ,   

    Get WordPress: Improving the Path to WordPress 

    For quite a while now, the meta team has been interested in improving the download and mobile pages on WordPress.org. Unofficially, we’ve been referring to this as the “Get WordPress” project. Here’s an overview of the thinking thus far.

    Note: The overview and proposal below are just exploratory to gather feedback.

    Overview

    Currently on WordPress.org, there’s are three related navigation items in use: “Mobile,” “Hosting,” and “Download WordPress.” Visitors to WordPress.org must select which “path” they want to follow.

    There are a couple of issues with situation:

    1. When a visitor clicks on “Download WordPress,” they may be expecting an immediate download of the software. Typical software websites don’t use the “Download” terminology if that package will not be immediately downloaded.
    2. Much of the content in the three navigation items is related. We currently duplicate content from the mobile page across the site when a user is on mobile, for example. Each of these pages is a different way someone can “get WordPress,” either direct to their computer, on their mobile device, or through a recommended host.

    Proposal

    There are a couple of approaches we can use to fix this.

    1. The easiest approach is to keep the three navigation items and update the “Download WordPress” button to immediately download WordPress.
    2. Conversely, we could rename “Download WordPress” to “Get WordPress” and keep everything in place.
    3. A third option is to rename “Download WordPress” to “Get WordPress,” and create a new landing page (/get/), removing the other two navigation items. Get WordPress would provide an overview of the WordPress mobile applications, a download button for the WordPress zip, and links to preferred hosts, as well as WordPress.com (this currently exists).

    I think the preferred option is #3 in the above list. For one, creating a page that is context-aware (mobile vs desktop) is a win-win for users on all platforms. Additionally, merging these pages gives visitors a full overview of how to get started with WordPress. By displaying these items on one single page, we can help communicate the purpose of each section and how they would relate to the visitors and each other more fluidly.

    Merging these pages also reduces the number of items in the main navigation and clarifies the main call-to-action button that exists across WordPress.org. We’d also want to ensure that we provide this merged page to all Rosetta sites.

    Information Architecture

    Here are both the current and proposed IA.

     

    download-current-IA

    Current IA

    get-revised-IA

    Proposed IA

    Feedback

    What do you think? We’d love feedback on the proposal above and this possible direction. Leave your comments below!

     
    • Abolfazl Ahani 7:18 am on March 1, 2016 Permalink | Log in to Reply

      +1 to option 3 of proposal.
      About Proposed IA: left sidebar (row 1&2, col 1), download software (row 1, col 2), mobile apps (row 1, col 3), website hosting (row 2, col 2), WordPress.com (row 2, col 3)

    • Mark Uraine 12:58 am on March 8, 2016 Permalink | Log in to Reply

      I’ve revised the IA a bit based on further discussion.
      1. Removed many of the links from the side-nav in the first section.
      2. Listing out the requirements in the first sections sidebar instead of linking to them.
      3. Moved the ‘Release Archive’ link under the ‘Release Notifications’ area in the first section.
      4. Moved WordPress.com as a sub-section of the hosting section.

      https://cldup.com/C0GrHwnHHG.png

    • Lara Littlefield 2:50 pm on March 24, 2016 Permalink | Log in to Reply

      This IA is helpful, but it doesn’t seem to answer the origin question of WordPress.com and VC-backed hosting’s prominence in these new mocks. I think the community would definitely appreciate clarity on that front.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar