Clarification of Screenshot Guidelines
The current guidelines for the Theme screenshot read as follows:
- Recommended 4:3 W:H ratio, size 600x450px (2x the previous 300x225px, to account for Retina displays).
- Maximum size: 600x450px
- Should be a “reasonable facsimile” of the Theme after it is initially activated with default options
I think a bit of clarification is in order, with respect to Themes designed to be used with a custom front page (i.e. front-page.php). I think that, in this case, the intent of the guidelines includes discretion to account for the design intent of the Theme. To that end, I would like to clarify that appropriate screenshots include the custom front page (front-page.php) display, even if that display requires the user to configure Settings -> Reading in order to display it.
Bear in mind that the original purpose of this guideline was to prevent undue marketing via the screenshot, either with unavailable “dummy” content displayed, or a screenshot that was a company/Theme logo, or that displayed something other than the Theme itself. A screenshot that displays the Theme’s front-page.php view is nothing like any of those mis-uses of the screenshot, and is a legitimate representation of the Theme.
What are your thoughts? Should the guidelines formally be clarified in this regard?
Edit
I forgot to mention: there is also an open Trac ticket to incorporate functionality to let Themes declare that they are designed to use a static front page, and “opt in” to that configuration as the default. If/when that ticket gets implemented, we’ll need to have this clarification anyway.
Emil Uzelac 1:05 am on January 17, 2013 Permalink |
Most definitely +1 from me!
Amy Hendrix (sabreuse) 1:05 am on January 17, 2013 Permalink |
Maybe something like “Should be a ‘reasonable facsimile’ of the Theme as it appears at activation, showing either the blog page or a static front page”?
I agree that the point was to avoid either totally uninformative images — logo-only screenshots or the like — or those that would take a ton of elaborate setup rather than looking something like they’d look out of the box. Showing the theme with a static front page displayed is totally within the spirit of the guidelines.
Edward Caissie 1:05 am on January 17, 2013 Permalink |
I think it’s a good idea to add this clarification regarding what different “views” the screenshot can show.
What also might be considered is “composite” screen shots that shows “responsive web design” (RWD) style themes such as a desktop/tablet/mobile collage? Personally I find that concept to be acceptable but something that can be referenced in this case may also help. For example, a collage style screenshot may only be used with a RWD style theme, etc.
Also to consider in the screenshot guidelines is the past idea of having multiple screenshots … if that is going forward(?) then the guidelines should be taking that into account as well.
Emil Uzelac 1:17 am on January 17, 2013 Permalink |
No doubt in my mind that (RWD) screenshots are good and +1, however we should also add that if (RWD) is in the screenshot, Theme should follow some type of guidelines in that regard as well.
Basically if one claims to have (RWD) Theme should be Responsive “all the way”, not just partially.
If needed, I’ll gladly put some guidelines for that
Chip Bennett 1:31 am on January 17, 2013 Permalink |
Under the current, one-screenshot limitation, I am against having “composite” screenshots. It’s partly an aesthetic thing (all the screenshots look similar when searching Themes, allowing the user to scan more easily the differences among the displayed Themes), and partly because allowing composites would necessitate another layer of bureaucracy in the screenshot guidelines.
However, I’m hopeful that the multiple screenshot idea will move forward in the near future, since it would make it much easier for us to support multiple views for Themes: not just responsive layouts, but also color schemes, and other configurable aspects of Themes.
Emil Uzelac 1:37 am on January 17, 2013 Permalink |
multi-screenshots is what I was referring to as well.
Edward Caissie 3:12 pm on January 17, 2013 Permalink |
I agree adding a “composite” screenshot guideline would definitely also add a layer of bureaucracy (that we do not need) but I also see it as something needed given the intent of authors to continue with RWD.
I also believe it would be better served by multiple screenshots being available in themes but until that is added to core this better idea really serves no purpose. Which leads to how do we get the “Multiple Screenshots” back on (core) trac? Such as possibly getting this reversed: https://core.trac.wordpress.org/changeset/20590
Frumph 1:08 am on January 17, 2013 Permalink |
Standard is 4:3 640×480 ratio which most screen grabs use because well, it’s a standard.
Chip Bennett 1:34 am on January 17, 2013 Permalink |
The current dimensions reflect HiDPI (Retina) support in the WP Admin, and should be as @nacin recommended to be used as the recommended guideline. We’re just following core’s lead on this one.
Emil Uzelac 1:40 am on January 17, 2013 Permalink |
That would be here http://core.trac.wordpress.org/ticket/21388 I believe.
Chip Bennett 1:48 am on January 17, 2013 Permalink |
Updated post to add a link/reference to this Trac ticket:
http://core.trac.wordpress.org/ticket/19627
Kirk Wight 3:44 am on January 17, 2013 Permalink |
I like Chip’s original idea: let’s state the screenshot must be from either the blog or front page view upon activation.
I also think it’s another layer of complication to allow composites or RWD views before we actually have multiple screenshots.
Konstantin Obenland 5:48 pm on January 17, 2013 Permalink |
I on’t know how much it’ll add to the topic of this discussion, but could serve as food for thought:
A user test on wp.com showed that a lot of people chose themes based on content images in the screenshot. Which obviously led to disappointment when they were not there after activation.
We started an effort, led by Lance, to update screenshots for “blog” themes, to not show any images that do not come with the theme. The goal is the same as this guideline’s goal: to not misrepresent what the theme will look like on activation.
kwight 1:17 am on January 18, 2013 Permalink |
Just curious what you mean by blog themes… as opposed to portfolio themes or similar, which can show images in their screenshots?
If a theme supports featured images, having a screenshot that demonstrates that makes sense to me, rather than ensuring no content images are visible. It sounds like wanting users to be pleasantly surprised, rather than possibly disappointed, neither of which is ideal.
Of course, it’s another situation that can be resolved once we have multiple screenshots per theme.
Justin Tadlock 5:04 am on January 21, 2013 Permalink |
The major point here is that the screenshot should not misrepresent the theme.
I saw a reviewer knock a screenshot the other day because a menu or widget wasn’t turned on by default but was in the screenshot. These are things that a user will configure anyway with just about every theme.
We just need to use a little common sense. This type of rigidness is what turned me off of the theme review team way back before I joined. Sure, we need standards, but when it comes to a theme’s screenshot, we don’t have to nit-pick every detail.
Ken Newman 8:02 pm on February 8, 2013 Permalink |
Agreed.