Using Flyout Menu to Administer Web Applications
For the next couple of days/posts (whichever happens sooner) I'm going to talk about the way I've come to handle a certain task in the web applications I work on. Namely the "admin" side of things.
We've all been there — you've created this perfectly-laid-out site and then realise you need to give the people who are going to maintain it a way to do so. I normally call this the "admin section" and, as it's normally an afterthought, gets plonked on the page wherever there's room for it. It normally consists of a set of links — some context-sensitive and some that appear on all pages. Normally links to actions such as "create new page", "edit document" and "view config settings". You know the ones I mean.
The problem with just sticking these links on the page somewhere is not only that it can "break" the appearance and take up much-needed space but also that the administrator no longer gets the same user experience ("UX") as the average user. It can also be an inconsistent approach - sometimes there, sometimes not. What's needed is a way of making these links available all the time, but in a non-invasive way. I think I've come up with the solution in the form of "flyout" menus.
You can see it in action in DEXT. It's a very rough demo and doesn't work in IE, but it gets the point across and there's a good reason it's Mozilla/Firefox only for now.
Before you can see the admin options go to the top right and hover over the Login link. A login form will popup. This too is what I've come to call a "flyout". You see them more and more now, but I'm not sure what the actual name of them is. Login as "dext admin" (password: dext) and you'll see an admin "link" appear top right. This too is a flyout. Logout and log back in as "dext user (password: dext) and it won't be there.
The beauty is that it relies solely on CSS to work and only a couple of lines at that. The basics of the CSS is covered by these rules:
#menu li div.flyout{
display:none;
}
#menu li:hover div.flyout{
display:block;
}
So, the flyout div is hidden by default but displays when you hover over the LI element that it lives in. It's just a shame that IE doesn't support the :hover pseudo-class doesn't work on anything other than A links. There's are hacks and workarounds to get it to work in IE, which I'll work on adding. For now I wanted to show it in its purest form.
Before I invest more time in the demo and accompanying article I wanted to gauge interest. Is this old news? Do you want me to make it work in IE and available to download? How do you guys go about the admin side of things?
Skip to the 
You can subscribe to an individual
To make it work in IE, change the page so that the element in question has an onmouseover option to unhide the div. Yeah I know it isn't nice and shiney, but at least it works in all browsers right from the start.
With an added benefit that if the Login option is an href to an actual login page, you now have a system which works even when the user doesn't have javascript enabled.
I know it's nicer to use a pure CSS version, but you cannot trust IE to conform to CSS standards like other browsers do.
I think you're talking more in the vein of a drop down, not a flyout. I only say that because flyout, menus/options have a history of problems for those with disabilities. With that said, I like your drop down login form, though you need to add IDs to the input elements so that the labels work. You might want to implement this using the Suckerfish drop down menus and putting the form in an LI. Also if you expect any of the menus or drop down forms to go over a list (select element), in IE 6 and below the list will bleed through. The solution is to add an iframe shim.
{Link}
Administration pages should not be an afterthought, I believe they should be just as beautiful as the site.
I'm very interested in knowing how you got the login to work without loading the custom login form. That alone would help me out a bunch.
The menu part isn't as interesting. Each line of my menus are a seperate document with a reader field which contains a list of roles. When a user logs in the roles that are assigned to him (or the group he's in) determine which roles he has and, thus, which navigator lines show up.
I've been using this system for 4 or 5 years now and it has made it easy for me to automate the changing of the many permission levels in my systems.
Best regards,
Rob:-]
For the most part, I use framesets for site admin. I've had good luck with them. (even though Jake says "Ney")
At any rate, this approach allows me to clearly seperate admin from UI and it makes for far less coding. That and ... it works with every browser. Additionally, with some clever targeted links you can have documents automatically load in a specific frame when opened for editing.
I've done computed subforms and such, but I finally got sick of the layout problems that Jake refers to. Framesets are not nearly as "high-tech", but my theory is to keep it simple and use what works. Additionally, you can cram lots into them.
Yes please invest more time, very useful information.
Thank you
YES PLEASE !!!
CSS driven menus have a bad habit in IE of having editable components bleed throuh as well. I am a firm disbeliever in Outline/Navigator approach to web site navigation and use a simple clean Dialog-Box (dropdown as my users call them) that performs a lookup against menu items. OnChange event triggers a JS function that takes the passed alias from that field and loads the appropriate view or form. The menu items are securable by either role , group or explicit user assignment.
For my Admin navigation, I merely have a second Dialog box performing the same function but on menu items specified under a separate category. Use a hide when formula to hide the admin nav field if admin role is not enabled for that user. If the app has very little in the way of navigation options, you can combine all menus into a single dialog box saving even more screen area.