Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • Speaking of Redesign Thoughts…

    Speaking of Redesign Thoughts…

    I caught this one on Twitter (and promptly forgot to blog about it in the 3.3 support craze).

    Thibaut Ninove, a Web & UI designer from Belgium, talks about pixels, web, design, standards and other topics on his blog, Dots & Thoughts.  He’s got a good one I know I’ve groused about before.  Why not put the ‘add media’ icon on the post edit bar?

    It’s there if you go into the fullscreen view after all:

    Add Media, full screen, GUI

    Add Media, full screen, HTML

    So clearly the hard work with the graphic is already done, and this would just be a case of moving it down a bit. The only reason I can think of to leave it one-out is that, pre 3.3, there were multiple buttons depending on the type of media, and that would have been kludgy. Now that the uploader is ‘fixed’ (it’s my favorite thing about 3.3), maybe 3.4 should move that in?

    Credit: My 2 cents about the WordPress 3.3 post editor | Dots & Thoughts.

  • WordPress Sidebars as Menus: Part 3

    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.):

    Manage Screen Options

    That gives me a brand new post meta box:

    Sidebars - The list

    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:

    Sidebars - Dropped Down

    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:

    Original Doodle Original Doodle

  • What to watch for in WordPress 3.3

    What to watch for: Javascript and Editor changes in WordPress 3.3 « WordPress Development Updates.

    I don’t generally just toss up a link and walk away, but Nacin nailed it in one, for what you need to watch out for with WordPress 3.3.  I’ve been SVNing it for the last couple months (very happily I might add) and only had one issue with a plugin.  Use Google Libraries stopped working for me.

    If you happen to be testing WordPress 3.3, or want to, the second Release Candidate came out this morning, and I’m keeping a Master List of all known issues, to be posted in the forums as soon as 3.3 is really real.  Any help finding bugs is appreciated!

  • WordPress Sidebars as Menus: Part 2

    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.

    More Compact

    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.

    Selecting a Location

    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.

    Hover Over

    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.

    New Sidebar Screen

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

    Jane's Suggestion - Green

    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.

    With Description

    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.

    Sidebar Logic

    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!

  • 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.

    Post Meta Menu Example

    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.

    Widgets in the DB

    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.

  • How Likely Is It That My Upgrade Will Fail?

    How Likely Is It That My Upgrade Will Fail?

    My father, Woody, is a risk analyst. So I asked him, knowing my math skills, where should I start learning about how to analyse and assess risk. With the personal commentary removed, here’s his answer.

    Math is not very important, at least not at the beginning. Risk assessment is really just thinking hard about answers to the 3 fundemental questions: what can go wrong; how likely is it; what are the consequences?

    Look at what you do at work. How can good answers to the three questions mitigate the (bad) consequences of poor decisions?

    Do a pilot study with an up-coming decision.

    Remember that what can go wrong? means an analysis from a choice or intiating event (like a 3-day power black-out in Chicago) of the sequence of events and failures of systems to control the events, bad human decisions, etc. Each sequence ends up in a bad situation or an ok situation. How likely is it? is just the likelihood of that sequence occuring, usually measured by a probability for each event in the sequence, either through data or expert judgement. What are the consequences? means that for every bad ending of a sequence, what are the consequences of that bad state.

    Make a decision-tree or event tree to enumerate the sequences. Each branching point (or top event) can have a fault tree to represent how that branch point fails or succeeds, or just expert judgement.

    Represent the likelihood of failure as a number between 0 and 1 (then success will equal 1-failure).

    Choose an end state for each sequence. Multiply the numbers for each branch point to get the likelihood of the sequence.

    Add up all the sequence likelihoods for the same end-state.

    That’s all there is to it.

    When you put it that way, it does look pretty simple.

    So I went through a proof of contcept process.  This is my first time making a fault tree, and I didn’t bounce it off my father.

    Fault Tree of a WP Upgrade

    As you can see, this is pretty basic. What can go wrong? A lot actually, and I wasn’t really doing more than picking the common problems. But this is a fault tree, not a decision tree. Are they different? They are! A fault tree is basically what you use to suss out why things go wrong. A decision tree though, we make a list of decisions and spin out what the liklihood of a failure is. So my decision here is “How should I upgrade WP? Stable or Pre-Release?

    WP Upgrade - Decision Tree

    Here you’ll see this is a similar enough, but wait! I have funny numbers! That’s my guesstimate at how likely these are to cause problems. See if you don’t have high tech skills, using SVN to upgrade is higher risk. In this world, you want a lower number. Like if you look at the stable release, you’d see that it adds up to a .4 failure, or a 1% that it’ll fail because of the upgrade tool or the user’s tech skills, but a higher 2% for ‘breaks’ (by which I mean you have a crappy plugin or theme).

    Now I left off things like for SVN/Nightly/Beta/RC you get the cool toys early, mostly for space and since this is a poof of concept. It’s clear that SVN is something only experienced people should play with, but it’s very possible I’ve scored Beta/RC too high. They’re sort of a break-even point, though. While Stable will always be recommended, I did a quick revamp of Nightly and Beta/RC. Nightly’s are more risky because you run a risk of getting an incomplete build (that is, some of my bored maniac friends may be checking in code, and not be 100% done when you run your update – a common weird issue with SVN and why I always svn up before I consider reporting a bug). But a Beta/RC is a ‘very nearly done’ cake, just missing the icing.

    WP Upgrade - Decision Tree Take 2

    Version two is, you can see, very similar. Personally I consider this a ‘start’ to understanding the risks inherent in a WordPress upgrade. If you held a gun on me and demanded I explain where I got the numbers, I would call them educated guesses, based on the forums, the mailing lists and my personal experience. Dad would say ‘Expert Judgement.’

    My next steps are to read up more on the process of using decision trees, directly in relation with software. While I certainly will also be looking into how a tornado in downtown Chicago would impact my office (can I get to work? No? Okay, so VPN. Can it take 5,000 people at once? Based on Snowmageddon last year, no. etc etc and so on), understanding the logic trees behind the forms is always my first step.

    To my WordPress friends, please let me know if I scored things too high or low in this one! To the rest of you, if you use these sorts of things in your jobs and, if so, how. I’d love to see some real-world applications outside the financial world!