Tag: design

WordPress Sidebars as Menus: Part 3
Who knew I’d be making a series of posts!? Part the Third is all about ‘per page sidebars.’ Inspiration struck as I was finally able to visualize how I’d want it to look, and it’s stupid simple.

First and foremost, it’s hidden by default in the Screen Options. This is important, since while I totally agree to use decisions, not options, this is something people need options for, but at the same time it is not something everyone will use. The fact that there aren’t more plugins that do it is paramount in that deduction. I know of two, after all, and one requires you to think. A lot. And while thinking isn’t bad, when you’re new, you want things to be straight forward and make sense. As subjective as that can be.

My idea is that by default, you use the default sidebars. Assuming you’ve defined them as I detailed out in my previous post, let’s play pretend…

Assumptions
1. I’m using the TwentyEleven theme with the following widget areas: Main Sidebar, Footer Area One, Footer Area Two, Footer Area Three, Showcase
2. I’m using a Static Front Page
3. I want a special sidebar only on that static front page
4. My theme uses a reasonable number of sidebars (i.e. 10 or less)
5. I’ve already setup my defined sidebar sets as follows:
  - Primary (for use on Main Sidebar)
  - Showcase
  - Footer left (for use on Footer Area One)
  - Footer middle (for use on Footer Area Two)
  - Footer right (for use on Footer Area Three)
  - Front Page Footer Left (for use on Footer Area One on the static front page only)
What’s that!? Front Page Footer Left? How ever will I define that? Where do I define it? If I only want that sidebar set (Chip, that’s for you) to show up on one page, I could either figure out how to select a page on the Widget/Sidebar editor, or I could do it on the Page Editor. For the purpose of this post, we’re doing it on the page.

Why? Well, it’s a split decision, and without any studies to back it up one way or the other, I suspect that people think ‘You know, I wrote this page, and I want a special sidebar here.’ and not ‘I wrote this special sidebar and want it to show up there on that page.’ My use of this/that and here/there were very purposeful. You think about the sidebars you want while you’re on the page they’re intended for. Therefore, you should define the sidebars on that page. The same argument could be made the other way, I’m aware of this. Just go with me for now.

We go to edit the page and first turn on manage sidebars(You can now see what other options I have going on.):

That gives me a brand new post meta box:

See why I said ‘reasonable number of sidebars’? This could get way out of hand, way fast. You may also note that they all default to … (Default). Well go back to my other idea of having a selection of where to use a sidebar and this makes sense. If you define a sidebar area back there, then that’s the assumed Default sidebar. When you want a specific page to have a totally different sidebar, we should store this information on the page, not in the sidebar/widget like we do today with Widget Logic, etc.

I can use the drop down boxes to show all the available sidebar sets:

Boom. I’m set for this page.

However. This doesn’t solve a big problem: What if I want a special sidebar for specific categories or archives? I’m still doodling on that one, but my first thought is what if certain ‘names’ were reserved. So if I made a sidebar named ‘categories’ it would automagically be used for categories, working on the same concept of the template hierarchy. All things being equal, it defaults to what you picked on the Widgets page.

By the way, these are the original doodles:
8 December, 2011
WordPress Sidebars as Menus: Part 2

Happy Thanksgiving. Here are some more ideas, partly based on the comments left in post #1. At the bottom is a gallery of all the various mockups, and feel free to download, tweak, etc.

Instead of a big Sidebar Locations box in upper left, what if you made location an element in the Sidebars themselves (Primary, Test)?

This has the location selection in the Sidebar Area itself. I’m not sure if I like the multiple saves, but if you have a long Sidebar Area, it seems sensible I made the space a big bigger with the idea that plugins could hook in and add things. More on that in a minute. You’ll also notice that there’s a scrollbar for the ‘Available Widgets’. Yeah, we lose drag/drop with this scenario, and while I agree D&D is very cool, it’s starting to get unmanageable when you want to drag a widget over to the area halfway down the screen. My grandmother said it was impossible for her to scroll in two directions (over and down) while holding down the mouse button. Mind you, she’s a 90-year-old with glaucoma.

Here’s what the dropdown looks like. Obviously we’re on Twenty Eleven here. The ‘blank’ is for ‘none’ which, on reflection, may need to become ‘(none)’ instead. It’s obvious to me that blank == none, but I’m not sure how new users would feel about that. Yes, my rounded corners suck.

Again, my colors and icons suck here, but this is a large pointer finger hovering over Custom Menu being told “Use this to….” My (minor) concern with this is that Akismet, for example, has the description of … Akismet. Singularly useless. You’d think it’d be better. But they’re not the only ones who slacked off on descriptions, so some of these will suck. Still, color it any which way and a hover-up will provide information.

The major concern I have, again, is accessibility. I’m hoping that this has already been hashed out before and we don’t have to invent something all new to allow screen readers to parse what things are for. That would be a deal breaker to me.

Here is the ‘new’ screen, complete with directions and a button.

By the way, since I suck at gradients, I opted not to make ‘Create Sidebar’ in the button, but that’s a nice idea too. Of course, with Jane’s recent post about the square button, that works too. I spun up a inverse of that, since it mimics the blue background and looks ‘obvious’ to me.

I LOVE the idea of a visual guide to where the sidebars are. Makes me think of Stephanie Leary’s layout fiddling with IDs:http://sillybean.net/downloads/widget-admin-ui-altered-with-ID.png (Trac ticket #18334:http://core.trac.wordpress.org/ticket/18334 – some other cool ideas there, too.)

I love Stephanie’s idea too, but. I really didn’t like the ‘uneven’ feel of her screen (not her fault, it’s just CSS layouts drive people to drink). Her’s works because you see where the widgets are going to go. I would want to have it be a wireframe. This is one idea for where to show the description, though I’m not really sold on it.

I know that Jane mentioned per-page widgets as a priority (maybe in IRC?), but we’ll have to wait until after the core team meet up to see what they decide on as goals.

On the other hand, I really like my idea for Sidebar Logic. If you’ve used Widget Logic, you get the idea. Put in the PHP to say ‘This Sidebar shows up on the Main Sidebar area IF these parameters are met.’ It’s not as ‘per page’ as Jane probably had in mind, though, and I’d like to see it avoid the need for PHP, but on the other hand, I’d love to see something plugged in there.

That’s all I have for you today, but here’s the Gallery, as promised!

24 November, 2011
WordPress Sidebars as Menus: Part 1

Okay, fine, not all widgets are used in sidebars. I’m going to use sidebar here to make my life simpler and trust you know what I mean. After reading Trac 17979 and Jane’s post on Wherefore Art Thou, Widgets? I had some thoughts.

Right now, when you switch themes, if the sidebar doesn’t match a new sidebar area, the widgets get dumped into ‘Inactive’, which makes if difficult if you want to switch themes for testing. Kbitzing on this on Twitter, like we do a few of us started kicking around ideas, most of which the ~~UI team~~ folks in dev-chat had already gone through.

My first draft was pretty straight forward:

But then Jane pointed out:

https://twitter.com/#!/janeforshort/status/138400574516375554
https://twitter.com/#!/janeforshort/status/138400669953564672

Which is true. I have over 20 available widgets here, and that list would get pretty damn long. While a list of checkboxes strikes me as less pretty, you would be easier able to manage this:

In either case, you’d want the widgets ‘box’ where they’re listed to be scrollable. I’m fairly sure you could make an auto-resizing box that grew and shrank by height depending on how tall your window is and then allow for scrolling the rest of the way.

At this point, we’ve reached the end of my practical knowledge. I know that menus are stored in the wp_posts table as a custom post-type called nav_menu_item. And then the actual data is over in the wp_postmeta table, where the post_id is the same as the ID from the posts table, and the _menu_item_* settings are where the magic happens.

On the other hand, widgets are stored in the table wp_options and not in the same way. They’re in one master field sidebars_widgets which stores all your information for widgets, which ‘sidebar’ they’re in, active or not. Each individual widget stores itself in widget_NAME.

Clearly it would be a bad idea to attempt to save the widget data in post-types, so we’d have to have some way to reach back and get the data. But if it were possible to toss the sidebars_widgets data over into the posts table, then they’d be brought over when you ran an export/import of your site much like menus are, which would make moving people off of MultiSite and over to their own site a heck of a lot easier, wouldn’t it?

This is as far as my thinking takes me, but it’s something I’d love to play with.

20 November, 2011
Community Driven Design

WordPress 3.3 is on the horizon, and already there’s a minor kerfluffle over the flyout menus. Regardless of if you agree with the change or not (I do, Otto does not, for example), it brings to mind the reality that every time there’s a new change to the Admin UI, someone demands to know ‘Who’ requested the change. One time, the answer was ‘Matt.’

While WP is open source, and that means it’s community driven, that’s only to a degree. Remember, at the end of the day the folks with commit access are the ones who decide what they want to support and have in their app. Theirs. WordPress isn’t a Democracy, it’s at best a parlimented monarchy, but really more of a benevolent dictatorship. This is neither good nor bad, when you put it in perspective, and I’m afraid that with products, especially free and/or open-source products, we as a user base consistently lack that perspective.

The company I work for recently switched to Office 2007. Yes, I want you all to take a moment to reflect on the fact that we didn’t move to Office 2007 until it was 2010 (and didn’t finish until summer 2011), it’s important. The reason we didn’t switch sooner wasn’t for anything technical. In fact, we really wanted to switch so we could upgrade SharePoint and have functional integration. No, there were no app conflicts or weird database issues preventing the upgrade. It ran on our operating systems without issues. But why didn’t we upgrade? Because some of the people in “very important positions” had trouble with it, and we were concerned that the UI change, which was rather dramatic, would overwhelm our help desk.

To put this in perspective even more, there are about 20k employees at my company (give or take, I’m not counting consultants here, or non-computer-using people). Of those, about an eighth are what I’d call techies. That is, maybe 2500 of us are really nerdy people who use foam swords or even know who Stallman is. Another 2500 of us are technically inclined, and capable of trouble shooting the basics. Another 2500 are smart enough to know how to explain their problem to the techs. That means over half the company are ‘real users,’ you know, the ones we make fun of for deleting DLLs that are taking up space, or who reboot their monitor. Every time we make a change to software used across the entire company, we have to put that 50% clear in our minds. How will this affect them? What training to we need to provide? We’ve pretty much accepted that no change will be universally accepted, and at a certain point we have to agree that this is ‘good enough’ for people, and deal with the fall out.

Coming back to Open Source, when a project like WordPress or Drupal makes a major change someone’s going to hate it. This is just the way of the world, and even if you love the change, you need to work to make sure your replies to these people aren’t ‘haters gonna hate!’ or ‘you suck!’ Neither of these are productive. Part of the problem here is that people get passionate and sulky, like a nine year old who viscerally dislikes something, but lacks the language to fully explain it. This is not to say people are incapable of explaining themselves, but that part of their problem is the ephemeral ‘feeling.’ The other major part of the problem is that no two people hold a hammer the exact same way. And of course that people who are complaining at the ‘beta’ stage of the product are in too late.

Understanding how these designs get made goes a long way into making people accept changes they don’t agree with. It doesn’t make them like the changes, but understanding how and why they happened can get you to the ‘agree to disagree’ point. John O’Nolan (who currently is living on the road by choice) wrote an amazingly informative post about how he got involved in WordPress UI back in the 3.0 days. He lays out how you can get involved more, if you’re inclined. There’s a great Make WordPress UI P2 blog, and of course WordPress Development blog that you can follow along to see what’s going on and there’s always looking at the tickets in Trac flagged for Needs User Experience/UI Feedback, but I’ve found the first way you should get involved is to start using WordPress trunk: the live latest and greatest, but not ready for prime time players, version.

That seems like a departure from theme, but it’s not. We all start out as basic WordPress users. We use the product, we know how to add/edit/remove posts, we move on to using plugins, and eventually we hit a wall. Either we start to adapt and become power users, who understand how to tweak things in wp-config.php, play with SSH/FTP, and make a quick child theme, or we resign ourselves to using WordPress as it is presented. Neither use-case is better or worse than the other. If you’re a ‘hard core’ WordPress user, though, you will find yourself wishing for small fixes, and you’ll make a plugin for yourself. Then you share it, and then you start to suggest things in the forums, or report bugs in trac. Now we’re cooking with fire, and it’s not long before you start tossing out code or css ideas for trac.

The point of this is that if you start ‘testing’ the new versions of WordPress at the beta or release candidate iteration, you are too late in the game to make a UI comment. The Beta and RC releases aren’t for making drastic changes, but for making the changes that are in there work correctly. Like how the ‘close’ button on the admin bar pointed isn’t working on IE 7 or 8. That’s a bug. But not liking the admin sidebar menu flyout and disagreeing with it entirely isn’t a bug. Did you know the head of the UI team didn’t like the Admin Bar back when it came about?

You don’t have to like everything about a product to use it, and sometimes changes mean you need to rethink how you use it. Also, WordPress has a policy similar to Apple and Amazon: Release, then iterate. That’s why in the last three releases of WordPress, we’ve had one major change and two noticeable tweaks to the whole admin UI. The 3.0 release was a huge overhaul, and in both 3.1 and 3.2 (and now 3.3) we’ve had significant variations on a theme. They feel big, but compare it to the 2.9 to 3.0 jump and it’s really pretty small.

If you want to guide WordPress’s UI, get in on it earlier than beta. If you want to iron out bugs, join at Beta, but take the time to learn the difference between ‘I don’t like…’ and ‘this is broken….’ If you want to get new features early, join at RC. If you want to wait till we’re ready to go, wait for the final release. If you just use WordPress and trust that most everything will work, use the final releases. If you’re annoyed that little bugs get missed, use RC. If you know you’re using a fringe case, or setup that uses normal WordPress but on an obscure server or configuration, RC or Beta is where we need you. Remember, not everything can be tested, but you can help test more. However. If WordPress is your life, if you live and die by WordPress and support people who use it or need to be testing it in your corporate environment, then you need to step up and start using SVN. Make a second install and set up a job to update every few hours, pay attention to release dates, and don’t treat this like ‘traditional’ software and wait for a release to be notified as to what’s going on.

But that is another post all together.

Perhaps the best thing about a cooperative design, like in an open source app, is that if you don’t like the changes, most of the time you can find someone else who doesn’t, and who wrote a plugin/extension to change it. When you compare that to, say, Microsoft Word, and remember that you, as a user, have very little say in things unless you luck into their market studies or beta tests, and even then, the locked down systems don’t always permit changes, well, you’ve actually got a lot of freedom. And if you’re not a techie, well, make friends with one or hire one. I hear a lot of them like beer.

26 October, 2011
How 17 Famous Website Looked In The Past: In The ’90s. You’ll Be Amazed | ImmatureBusiness

Remember those times in the ’90s when you had to type WWW. and websites looked dull, boring, and full of moving and annoying flash banners. I’m sure nobody wish to go back to those times. Now, websites are focusing more and more on the user experience, loading speed, and subtle ways to locate ads without distracting the content or function.

via How 17 Famous Website Looked In The Past: In The ’90s. You’ll Be Amazed | ImmatureBusiness.

26 September, 2011
Multiple “Share This” On Your Front Page
So you want people to be able to easily share your posts, and you install Jetpack and configure it so that the happy icons only show up on posts and pages (since you can’t make it show on only posts).

Then you decide to make a Static Front Page so everything looks pretty. Except you get multiple instances of the sharing links! That isn’t what you wanted at all!

The problem is that the when you make a static front page, it’s actually not an index page. It is simply a page using a template. Strictly speaking, it’s not an archive page, nor an index page, and because of that it’s treated like any other page and the ‘share this’ settings treat is ‘correctly’ by showing itself every time a page/post is called. I did report this to Jetpack, by the way, and they were a bit torn on if this is Jetpack being silly or something that needs to be addressed in core (that is, does WordPress need to grow up and treat a static front page as an index page).

While they’re hashing this out, you can fix it yourself, which is a relief to those of us who ran into this.

The easiest (and actually best) way is to use the WordPress template hierarchy to your advantage. If you use a front-page.php file instead of a static front page, WordPress knows that it’s an index page. This is the best way because you don’t make any extra ‘calls’ to the code. WordPress tucks it away on it’s own. To do this, if you’re using a page template, just copy the template (say page-snarfer.php) into front-page.php and call it a day. Depending on your theme, you may need to add a call to any special classes being called. (I know that if you use Hybrid Core, you need to add a call to page-template-home for it to format right.)

But sometimes you can’t do that. Like if you’re on MultiSite and you use the same theme for multiple sites and you don’t want them all to have the same style of front page. Well now we have a minor problem. First thing to do is turn off sharing for the page you’re using as the static front page.

Doing just that brought me to this:

In this case, I’m using a static front page with some content, formatted via the Twenty Eleven “Showcase Template” to show recent posts below my content. The first post shows up as an excerpt and then the rest show as titles with links (apologies for the different color):

So for this theme it works perfectly and I’m happy as can be. This method also works if you’re using a Static Front Page without a page template!

But. That doesn’t work for all themes. And this is where we have to do the ugly things we don’t want to do. We have to edit CSS. In and of itself, this is pretty easy but I think it’s a poor choice because all this will do is hide the icons from displaying, and that means the code still gets rendered and call and that means you’re putting more work into loading your page than you need.

Sometimes you just can’t fix it the best way, and acknowledging that, here’s how to do it. First, you must be using a page template for your static front page. (I said this once before, but it bears repeating: If you’re not using a page template, you can fix this by just turning off the sharing for the page.) Open up that template and look for something like this:
```
<div id="primary" class="showcase">
```
Once you’ve found it, you just have to add in a CSS call:
```
div#primary.showcase div.sharing {display:none;}
```
That says “In the primary.showcase div, if anything’s using the div sharing, hide it.” Not the most elegant or efficient way about it, but it gets the job done.
9 September, 2011