[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