[wp-trac] [WordPress Trac] #12412: Tab interface for Theme and Add New Theme

WordPress Trac wp-trac at lists.automattic.com
Sat Mar 27 21:12:26 UTC 2010


#12412: Tab interface for Theme and Add New Theme
----------------------------+-----------------------------------------------
 Reporter:  matveb          |       Owner:                  
     Type:  task (blessed)  |      Status:  new             
 Priority:  normal          |   Milestone:  3.0             
Component:  UI              |     Version:  3.0             
 Severity:  normal          |    Keywords:  has-patch commit
----------------------------+-----------------------------------------------

Comment(by jeremyclarke):

 Replying to [comment:20 carlhancock]:
 > Replying to [comment:19 JohnONolan]:
 > > Many thanks for your response - I will try to make it to the UI group
 chat sessions in future so that I can give my suggestions much earlier :)
 >
 > Ditto.  I was unaware that the discussion had taken place elsewhere.

 Are you guys on the wp-ui mailing list? It's like wp-hackers but for UI
 stuff and there was an extremely long discussion about this there.

 http://lists.automattic.com/mailman/listinfo/wp-ui

 I'm still not sure about the idea even though I was promoting the
 implementation that got used in the end (big tabs same size as other
 headings). Overall I feel that if we use something like this it should be
 available to plugins as well, though that's a recipy for problems with the
 current design.

 Jane I like that you are framing it as an experiment. That distinction is
 important in that plugin authors should '''not''' be trying to emulate
 /reverse-engineer the effect, but instead should wait for it to be
 finalized in 3.1, then use whatever API is attached to it (e.g. new
 functions or argument for existing functions that add paired pages).


 My feeling is that this is not the best system, and that the way in which
 you are trying to amalgamate screens is the problem. It just feels too
 nebulous. I think a better solution would be to work out a UI that
 presents all siblings of the current screen (other pages in the same
 sidebar section) in its header, not just one. This way the groupings
 established for the sidebar are just re-iterated in the header. I think
 this would be easy for people to grasp and would solve the current
 awkwardness around finding a sibling page from a section that is low in
 the sidebar. I feel like it is natural to expect the siblings to be
 accessible from the page content, thats my muscle-memory instinct or
 something. THAT SAID: I don't know what kidn of UI would be good for this,
 especially one that would account for potentially long lists of related
 pages.

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


More information about the wp-trac mailing list