#12412 closed task (blessed) (fixed)
Tab interface for Theme and Add New Theme
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | 3.0 | Priority: | normal |
| Severity: | normal | Version: | 3.0 |
| Component: | UI | Keywords: | has-patch commit |
| Focuses: | Cc: |
Description
make.wordpress.org/ui/ experiment for a tabbed interface. Starting with Theme and Add New Theme areas.
Attachments (8)
Change History (46)
#2
@
15 years ago
Not sure if this was fixed in the tweaks, but the tabs were slightly closer together on the Add New page.
Also, -moz-border-radius has a different longhand than -webkit-border-radius. Example: -moz-border-radius-topleft versus -webkit-border-top-left-radius.
#3
@
15 years ago
Nacin, we are working on that the tab spacing now.
Will also take a look at the radius glitch.
Thanks,
Dre
#7
@
15 years ago
In the meantime, I'm going to push the Add New Themes link to the bottom of the list..
#11
@
15 years ago
Todo:
- Move colors to the color stylesheets
- Support both Blue and Gray color schemes
- Support RTL
#12
@
15 years ago
Aren't the styling of these tabs completely inconsistent and out of place with the rest of the WordPress UI?
If you are trying to make tabs a new navigation element that can be used in other areas of the admin down the road, having them so large is not going to be scalable.
I can see the tab UI being adopted by plugins in the future, and with them being this large it isn't going to be very scalable for a bunch of tabs in this area. It seems like the tabs shouldn't try to be integrated with the header text, but instead be located where the current "Search, Upload, Featured, Newest, etc..." links are now.
#13
@
15 years ago
@carlhancock: This is not meant for plugins to use AT ALL. It is a navigational experiment, and the style is based on existing styles. Could it better? Yes. Is it inconsistent with the rest of the UI look and feel? No. Wireframes were also produced with small tabs in the text filter area, and they were not approved for a number of reasons. If you don't like the tabs on this screen and aren't willing to wait out the experiment for them to evolve, I would suggest writing a quick plugin to revert it to the old way. Otherwise, just don't worry about it so much and let the experiment do its job, to inform a broader application and the design of tabs in the UI in 3.1
#14
@
15 years ago
Replying to carlhancock:
Aren't the styling of these tabs completely inconsistent and out of place with the rest of the WordPress UI?
If you are trying to make tabs a new navigation element that can be used in other areas of the admin down the road, having them so large is not going to be scalable.
I can see the tab UI being adopted by plugins in the future, and with them being this large it isn't going to be very scalable for a bunch of tabs in this area. It seems like the tabs shouldn't try to be integrated with the header text, but instead be located where the current "Search, Upload, Featured, Newest, etc..." links are now.
Completely agree with Carl, it doesn't make sense to have a whole bunch of tabbed H2's which are all bigger than the main H1 - looks a bit out of place. It this is to be used for more than just the "themes" page then it's worth noting that we won't be able to fit more than 2 or 3 tabs inside the standard 960px width resolution.
#15
@
15 years ago
@JohnONolan: As I just stated in response to Carl, this is a UI experiment, and is not meant to support lots of plugins adding tabs, etc. We may refine it between now and RC if it turns out that we need to for usability reasons, but it is using the existing h2 sizing because it is two screens in one. There will only be two tabs, as it is for a very specific dichotomy (manage/create). Freeze is now in effect though, so it's in, and hopefully you'll grow to like it. If not, if you wrote a plugin to revert it, I'm sure Carl would use it. :)
#16
@
15 years ago
Hi Jane, while I think the format could be better, I understand that the decision has been made to use it.
Could I offer this mockup as a suggestion of how I think that same format could be improved, with only some minor changes?
Primary changes:
Font in tabs made slightlight smaller to accomodate for more tabs if necessary, this also takes away less from the H1 on the page.
Alignment of tabs with top of the "manage themes" icon fixed.
Alignment of tab line (bottom) with dividing line in left menu fixed
Grey bg with white border added to inactive tab to mimic style from left menu, and provide visual contrast between active and inactive tabs.
#17
@
15 years ago
I forgot to mention that I changed the wording from "install themes" to "add new" because I think this fits with the current Wordpress conventions, for plugins in particular.
Say I'm a user, and I've just downloaded an awesome theme that I want to use on my site. I'm running Worpdress for the first time, and I want to get this theme working: I go to appearance, and I see "Manage Themes" or "Install Themes" - I'm going to click on "Install Themes" because that suggests that it's where I should go to set up this new theme that I have. Of course this would be a big mistake, as themes are added and activated through the "Manage" screen.
Hope you know what I mean!
#18
@
15 years ago
@JohnONolan The size is the same as current screens. For now there will not be additional tabs. When we get through the freeze tickets, I'll try to write up a post on the tabs and all the discussion that went into them in the UI group and the dev chat, but for now I am not going to change the design until we get to the user testing part of the cycle, which will be in a couple of weeks.
#19
follow-up:
↓ 20
@
15 years ago
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 :)
#20
in reply to:
↑ 19
;
follow-up:
↓ 25
@
15 years ago
Replying to 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.
#23
@
15 years ago
+1 for having some sort of tabs there, please check this as well (incl. screenshots): #9657.
There are tabs with the plugin not totally the same but I would be happy if there are some subtemplates to create those in admin.
#24
@
15 years ago
$api->$key now does notices:
Notice: Undefined property: stdClass::$requires in \wp-admin\includes\theme-install.php on line 459
Change in theme api?
Long gab between here and #8652, that one marked as needs-testing but closed. There is a note in the function saying it ain't finished (since pre-2.8). Take care.
#25
in reply to:
↑ 20
@
15 years ago
Replying to carlhancock:
Replying to 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.
#27
@
15 years ago
In WP3 Beta1, the Manage Themes tab is removing the space between the tabs. This was working in Alpha.
See attached screenshot. http://core.trac.wordpress.org/attachment/ticket/12412/Screen%20shot%202010-04-05%20at%206.54.45%20PM.png
#28
follow-up:
↓ 29
@
15 years ago
Whether or not it was "working" in Alpha, the lack of spacing looks fine for tabs of that design. The question is, was the change intentional?
#29
in reply to:
↑ 28
;
follow-up:
↓ 30
@
15 years ago
Replying to voyagerfan5761:
Whether or not it was "working" in Alpha, the lack of spacing looks fine for tabs of that design. The question is, was the change intentional?
Fair enough. At the end of the day, the spacing between the tabs should be equal from either page. If the tabs are touching each other or have space between them is another topic, my take is they should match one way or another. :)
I am happy to make the changes but need to know which way is what is wanted before I work on it.
#30
in reply to:
↑ 29
;
follow-up:
↓ 32
@
15 years ago
Replying to dremeda:
Fair enough. At the end of the day, the spacing between the tabs should be equal from either page. If the tabs are touching each other or have space between them is another topic, my take is they should match one way or another. :)
I am happy to make the changes but need to know which way is what is wanted before I work on it.
You are correct, of course, and I apologise if it felt like I was jumping down your throat with my comment. The tabs should definitely match throughout the interface. Would I be justified in creating a ticket (assuming one does not already exist) for a function in core to generate tab bars? Consistency would be simpler if there was an API.
#31
@
15 years ago
No worries mate!
You can create a ticket but even if it gets approved, it won't move until 3.1 or later (WP3 is frozen). I encourage you to open a ticket if you feel it will help, I would be interested to see what you're thinking more in depth.
As for the existing tab spacing issue for this release and this ticket, as soon as I hear from Ryan, Nacin, or Jane, I will take the appropriate action.
#32
in reply to:
↑ 30
@
15 years ago
Replying to voyagerfan5761:
Would I be justified in creating a ticket (assuming one does not already exist) for a function in core to generate tab bars? Consistency would be simpler if there was an API.
Voyagerfan If you read Jane's comments above she mentions that this is a bit of an experiment, so it makes sense that there is no API yet because it is not set in stone. A ticket for 3.1 that solidifies the tabs into an API makes sense, but it shouldn't be applied to anything else until after this particular change has been assessed.
About the spacing: I think having them smushed toghether is a LOT worse than having some space between them.
The .menu-tabs class needs between 2px and 5px of margin right, I.e.
margin: 0 5px 0 0;
#33
@
15 years ago
Jeremy's right, the tabs are an experiment. They've been working well so far in the alpha, but there's no intention of spreading them out through the admin for 3.0 based on beta performance. The experiment was more, 'see how they do, and if they're doing okay, leave them on the themes screen for 3.0, and start thinking about how to use them elsewhere in the admin for 3.1, and at that point work out a more extensible method and design. So if there were going to be an API, it would definitely not be until 3.1.
#34
@
15 years ago
Margin changed. It was 6px. See file attached.
http://core.trac.wordpress.org/attachment/ticket/12412/wp-admin.dev.css.diff
#35
@
15 years ago
Attached patch doesnt work properly, It adds the spacing on the Manage Themes page, Removes it on the Install Themes page.
#36
@
15 years ago
Of course, That could just be because of a stray margin change in my local install.. Removing the margin entirely from .menu-tab-inactive and only having it in .menu-tabs looks better to me.
First try.