Starting next week, we’ll be attempting to follow an agenda during the Wednesday dev chats. If you would like to propose a topic for the July 8, 2009 dev chat, please submit it in the replies/comments to this post. We’ll post an agenda the morning of the dev chat (i.e., about 8-10 hours in advance).
Updates from jane RSS Hide threads | Keyboard Shortcuts
-
Jane Wells
-
Jane Wells
There was some talk last night about maybe doing a little design brushup on the admin header/nav. We only have a couple of days to decide on the design changes if we want to include it in 2.8. Would like to give community designers the opportunity to do a mockup (could give them a psd of the current style), but since they’d need to submit their design suggestions by Monday, and I’m nervous that there might be some backlash for the short/no notice. I mean, MT didn’t get any notice either, so it seems fair. It’s a pretty small design job… Jaquith did a quick mockup in 5 minutes. If anyone does take up the challenge, we can post the comps for a vote on Tuesday. What do people think?
-
Jane Wells
We decided to do it. Posted on dev blog here: http://wordpress.org/development/2009/04/design-tweaks-whos-in-an-idea-in-three-acts/
-
-
Jane Wells
Writing up explanation of new dashboard for dev blog.
-
Jane Wells
Have gone through a list of fixes/updates with Ryan, Andrew, and Mike. Current list of things to do…..
Pre-design stuff:
Reduce font size in nav, make subnavs smaller than nav section headersSince Favorites menu will just be presets for 2.7, need to decide final list of presets.
Andrew doing some work with base blocks of CSS, looking at fixed vs percentage width of some columns.
Dashboard:
- Show Edit links when hover or clicking in module.
- News Feeds, Mike working on display styles.
- Should we change Edit in comments to Quick edit, and only allow inline editing of comment text, nothing else? (rather than sending to edit screen, though it’s nice that after saving it returns to dashboard. except it returns to specific comment at top of page, hiding portion of main area under header div)
- In recent drafts module, add date to list items
New post screen:
- Add media icons (Upload) and Embed above post editor
- Make visual/html tabs flip up again instead of down
- Media added module being removed for 2.7.
- Publish module will probably change a little depending on final design (but will be closer to wireframes than current live version).
Edit posts screen:
- Add a media column in table. could just have number of files instead of listing them if space too much at a premium (like comments), and maybe show thumbs in excerpt view.
- Excerpt view messes with column widths, should retain widths from list view.
- Remove status column, replace with inline status display per wireframes
- Add “- Draft”, “- Private” and “Password-Protected” after post title when applicable in View All. do not show extra label when in filtered view.
- In excerpt view, add line break between date and time
- Quick edit: remove the password protect (unless it is password protected already) and sticky modules
- In batch edit, when listing the selected posts, change alt text for the x icon from selected posts to ‘remove from batch edit’
Tags:
Apply new layout per wireframesCategories:
Apply new layout per wireframesMedia Library:
- Need updated screen for add new
- Edit. update table per wireframes
Links:
Add New. Restyle page so the first three input fields don’t take up 3/4 of page. Simple form style, label on left (aligned), input on right.Link Categories:
Restyle page according to categories screen layoutPages:
Add page order to the column on Edit screen so can be changed in quick edit.Comments:
- Moderate. make gravatar/name link to URL as before
- For .com, add My Comments to subnav
Appearance:
Widgets. Will add notification reminding people to click on save changes at bottom of widget column to make changes take effect, no time to do major overhaul of widgets screen.Plugins:
Installed. People were saying there’s not enough room for actions in the action column. Could that list actions vertically so people could have room for their actions like configure etc?Users:
Andrew playing with options for making add new user form easier to notice and get to, deciding between several approaches.Tools:
Only if there winds up being a little extra time: We should probably create a tools page and put press this and turbo on it, with links to tag/category converters on Import page. Agree with comments raised on hackers. Can just have basic layout of intro line like “The tools below can improve your blogging experience” or something, and then just have the content as is one after another until we have more tools we want to pimp.Settings:
- General. For date format and time format, will put a few of the common choices in a dropdown or radio button list and have a choice for Other with self entry according to codex. Add “5 September, 2008″ format and 24-hour clock time format to list of choices.
- Need to include Delete Blog somewhere (for .com). Am thinking it should go under General settings as a teaser item, and then lead to the full page (puts an extra click in the way of unintentional deletion).
-
Jane Wells
Wow, those visual editor bullets are ugly with this theme.
-
amfprod
It’s unfortunate there’s no time to overhaul the widget admin. Hopefully that gets some attention in 2.8.
-
Jane Wells
amfprod: Yes, we wanted to overhaul the widget admin, but unfortunately that screen has a lot of complicated code behind it, so it wasn’t as simple as just making a new wireframe for layout/functionality suggestion, like with some other screens. Because themes need to be able to tie in to the widgets functionality, there are backwards-compatibility issues that make it necessary to spend more time working with the code for widgets. 2.8, definitely.
-
Kirk M
Very glad attention is being paid to reducing fonts a bit. I’m wondering though, is the blog title font going to be reduced? At 36px it throws the entire Admin header and navigation rendering off with a longish blog title at 1024×768 resolution. I’ve had to change line 671 (now line 661 with the latest builds) of “wp-admin.css” from 36px to 20px just to straighten things out and make the “Page Options” link accessible on certain Admin pages.
Otherwise, I’m find myself enjoyinh the 2.7 Admin layout quite a lot. Fine job so far, all.
-
jane
Hi Kirk. Yes, the blog title font will be reduced in size when we start applying visual design styles over the next couple of weeks. Page Options link will likely be changing position slightly as well.
-
Dean
Great list, interested to see how the new tags/categories layout turns out. Also really keen to see some of the new visual design appear in the nightlies.
-
Pet
Looking forward to development in trunk! I humbly hope that again the spirit of the first focal point of the slogan is maintained: “WordPress is a state-of-the-art publishing platform with a focus on aesthetics, web standards, and usability.” I guess I am not the only one that was attracted to wordpress by those words a few years back already. I hope the final administrative backend design will stay clear, spacious and soothing, where it is relaxing to visit daily — no cluttering, weird icons and unnecessary box borders (even double borders!) like sometimes seen with fellow software like Joomla or Drupal. Please let us live free amid the pressures of streamlining.
-
Jane Wells
Dean: the proposed layouts for the Tags/Categories screens are shown in the wireframes we posted recently. I think those screens are still up for grabs in terms of coding the changes/CSS if anyone wants to volunteer.
>>Ryan, please correct me if they’ve been assigned since yesterday.
-
Michael
I upgraded to 2.7 yesterday and I’m reserving judgment but think I’m among those that think menus at the top were *generally* better than along the left side.
My two main complaints so far are that Georgia is a terrible font for the visual editor. I would like to be able to toggle to a sans serif font…heck, I’d like themes for the admin interface.
Secondly and more importantly, on the new post screen, categories are shown in their parent/child hierarchy but they are not on the edit post screen. I make may more posts editing an unpublished post that’s configured to be used as a template. It has three default categories and they’re pre-selected and shown at the top of the list as they should be but two more categories need to be added each time and they’re much easier to locate (I use over 100 categories) if the parent/child relationships are visually supported.
I really like the “screen options” features of 2.7.
Jane Wells 10:24 pm on July 1, 2009 Permalink |
I will want to discuss the rankings from the feature poll that we’ll have up by then. It will still be running, but we should have a few days’ worth of votes, which is when we get the bulk of them anyway.
Denis de Bernardy 10:29 pm on July 1, 2009 Permalink |
If I may, it’s going to be much more important to find the volunteers to code the stuff.
Jane Wells 10:56 pm on July 1, 2009 Permalink
True, but we can’t very well assign volunteers to specific feature development if we don’t know the features, and we don’t want to decide features without community input (as opposed to the core devs and or just the dev chat making these decisions). So while finding volunteers is super important and definitely harder than deciding features, we do need to decide the features as well.
Denis de Bernardy 7:35 am on July 2, 2009 Permalink
Indeed, but at the end of the day I tend to remain very down to earth on this kind of thing.
End-user feedback is meaningless if nobody shows up to code their requested features. On the contrary, asking for such feedback can have a negative impact. If those who are coding patches ignore the feature requests and prefer to focus on other things, you end up in a situation where users go “WP Devs ignore their community’s input”.
Thus, please make sure someone’s willing to code feature A, B, C before submitting it to any kind of vote.
Jane Wells 2:12 pm on July 2, 2009 Permalink
That point of view is in direct opposition to the idea of letting the full community have input into our feature set. Worst case scenario is that the core devs code features no one volunteers for and it takes longer, so knowing the priorities of the broader community is imperative in deciding which features they should focus on first.
As with every vote, we make it clear that the vote is to influence core decisions, not to make them, so your argument does not convince me that we should forego voting before assigning developers to features. There’s no point in coding something that isn’t important to the broader community, and we aren’t going to put features in core just because a developer offered to code it, if it’s not to the benefit of the wider community.
Community opinion + technical considerations + developer availability = How core decisions get made. We need all three factors to make a decision.
Matt 4:30 pm on July 2, 2009 Permalink
If something is important and worthwhile, we’ll get it done.
Sometimes that means working on un-fun things but that’s okay.
Peter Westwood 7:22 am on July 3, 2009 Permalink
There is no point coding features that people don’t want just because someone wants to code them – that is just adding bloat
We need to know what the community desires so that we can focus on the right things.
Denis de Bernardy 10:28 pm on July 1, 2009 Permalink |
bugs, bugs, bugs, bugs. there are too many in trac, they need to get fixed/addressed, and there are bottlenecks to getting them tested and fixed. I stand by my opinion on this. the short short version is: need… more… committers…
Matt 4:30 pm on July 2, 2009 Permalink |
We need to be careful as we go through tickets — I feel like a blind chasing of low-priority bugs in the last dev cycle delayed the release and the resulting changes introduced instability we haven’t had in a few releases, regardless of the arbitrary metric of # of tickets in trac.
Xavier 10:39 pm on July 2, 2009 Permalink
True enough. In my 2.8-presenting post on WPFR, I came out hoping that the sheer number of tickets solved was proof that 2.8 was among the cleanest and most stable release since a long time. Turns out that’s wrong, since 2.8.1 comes with a bunch of bugs that (AFAICT) should have been spotted earlier.
While I can’t be against more committers, I’d be also in strong favor of asking for more tests, insisting the original reporter (and participants to the tickets) to make sure an issue is indeed fixed without side-effect, and maybe build more automated & user tests?
Insisting on community leaders to have their staff and community make real-world tests of betas and RCs (with according test plan sheet, even?) ? I’m afraid a lot of us tend to rely on the “hey, core-devs are good, no need to worry. oh shoot, that feature is b0rked. bah, they’ll prolly know about it, it’ll get fixed eventually”.
Typing while thinking, not sure that’s legible. Short version: moar testing.
Peter Westwood 7:20 am on July 3, 2009 Permalink |
Just because there are a lot of bugs in trac does not make the software very buggy.
We need to hit the big issues and deal with some of them each release.
Any attempt to “fix” all the bugs in trac in one release cycle would just make things worse.
I don’t see that adding a huge chunk of committers improves anything.
We need a small number of good well tested patches which hit the big bugs.
A slower more heavily tested and reviewed development process produces more stable software than one where you just chuck all the fixes in you can find and hope they work.
Getting more people involved in things like automated test writing would be a big help – this means we can get good validation on the functionality at a low level which we are building upon