[wp-trac] [WordPress Trac] #25094: Twenty Fourteen: Audit Theme Customization Options

[WordPress Trac]

#25094: Twenty Fourteen: Audit Theme Customization Options
------------------------------+------------------------------
 Reporter:  celloexpressions  |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Bundled Theme     |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |
------------------------------+------------------------------

Comment (by celloexpressions):

 Let me clarify the "why" of this ticket (I sense an underlying "why would
 we remove these wonderful features"). Obviously, I'm not suggesting that
 we remove features for the sake of removing features, or even because of
 code bloat. I'm more worried about user experience and
 **[http://wordpress.org/about/philosophy/ decisions, not options]**. Since
 decisions not options is a core philosophy, and Twenty Fourteen will be
 the default bundled theme, we should be deliberate about what options
 we're packaging with the default experience. It makes much more sense to
 add functionality with plugins than to overwhelm new users with
 functionality that's there because it only takes a few lines of code and
 could be useful for ''some'' users. I think Twenty Thirteen and
 [http://wordpress.org/plugins/thirteen-colors/ Thirteen Colors] are a good
 example of adding edge-case theme options via a plugin; users who want
 more advanced features are also more likely to know to look for plugins.
 On the other hand, we need to make sure that users have the ability to
 easily customize their site to some extend; my primary goal with this
 ticket is to work on finding that balance.

 So, with that out of the way, here are some more specific thoughts on the
 feedback others have left:
 - Is anyone ''against'' adding one or more colorpickers to customize the
 default green accent colors? This is one case where I think a majority of
 users would appreciate a default UI for customization. I see at least
 three different shades of green; should we generate lighter and darker
 variants of a custom color or include multiple color pickers for this?
 - The main reason I'm unsure about the ''need'' for a header image is that
 there is no image by default, the demo site has no header image, and none
 of the sites running Further/Twenty Fourteen that I've seen use it. I
 didn't even realize that the custom header feature was being used in
 Twenty Fourteen until I started digging through the code (I was suspicious
 of the header text controls in the customizer, since the header image
 section is not present until images are uploaded). That's clearly a
 problem with the core feature, but combined with the lack of use,
 decisions not options, and the javascript thing, I think we should
 consider whether we really need it (and fix the core implementation at
 least of no-image-by-default header UI if we do need it). Twenty Thirteen
 didn't do custom backgrounds, maybe Twenty Fourteen shouldn't do custom
 headers (which would also further distinguish it from previous default
 themes).
 - Thinking from a (first time) user's perspective, the "Header Text Color"
 label logically applies to all of the text in the sticky header, not just
 the site title. The only reason that this option would make sense as
 title-only would be following conventions from other themes. And
 generally, just because the customizer gives the user instant feedback
 about exactly what a given option does doesn't mean that it shouldn't be
 clear before any interaction and behave logically. A user that wants just
 the site title to be a different color is probably an edge case.
 - "Display Header Text" again seems referable to all of the text in the
 header, not just the site title (especially for users who can't
 differentiate navigation from text). And that really doesn't make sense.
 It looks like we can keep header images but drop the header text color and
 header text controls by specifying {{{'header-text' => false}}} in
 {{{twentyfourteen_custom_header_setup()}}}, perhaps that's worth
 considering?
 - To clarify, I think we should consider dropping header image support in
 order to ''improve'' the fixed header. The fixed navbar in Twenty Thirteen
 (#24184) had a fair amount of support, but not from most of the final
 decision-makers. We'll need to add a whole bunch of additional JS to make
 the fixed header work in IE (as we did in #23841 for Twenty Thirteen). It
 currently doesn't work at all in IE (including 10), see (#25144). So in
 summary, rather than going down the same path as in Twenty Thirteen and
 potentially eventually removing the (much more functional) code-heavy
 Twenty Fourteen header, let's seriously consider whether a currently
 barely-if-ever-used feature (header image) is more important. If we drop
 header images we can do the header without js.
 - I do think we should keep custom backgrounds ''because'' we aren't doing
 #25013, I was just including that for completeness. I would be interested
 in the percentage of users who would prefer the #25013 suggestions over
 having a more visible & customizable background, though. Slight annoyance:
 the majority of users won't be able to see the background at all in the
 customizer.
 - The social links thing is an interesting issue. I also like the design
 direction and think that this sort of thing should be implemented in a
 default theme since it's difficult to integrate the design with a non-
 theme-specific plugin. But I think the current configuration is a non-
 option because of the annoying UX of where the data is stored (and how
 easily it is lost). This seems like a good opportunity to seriously
 consider storing some social information in core or having a (permanent)
 core plugin for it. Having a canonical place for social links would
 ultimately be a better user experience than adding social details for
 every social plugin/theme that needs the data. But on the other hand, it's
 more bloat and the concerns about user-specific social media in #11541 are
 applicable here as well. Long-term maintenance and potential eventual
 removal would also be strong arguments against putting it in core. The
 easiest solution for Twenty Fourteen is removal of that feature entirely,
 unfortunately.

 Sorry that was so long, but I think it's important to take a step back and
 look at this from some different angles. And of course, this requires a
 lot of discussion since there are so many components involved.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25094#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software