A List Apart

[shadendorain]

If you design for the web regularly I highly recommend reading through some of the articles at http://www.alistapart.com. They cover several programming languages as well as best practices of both design and coding. The also discuss the pros and cons of various implementations including browser compatibility issues. It's not a "reference" type resource but it can help greatly with design delimmas.

I mention this particularly because they have several solutions for dealing with forms that might be more elegant than the way they're coded in v2.0. See: http://www.alistapart.com/articles/pret ... ibleforms/

[Falcon]

I know the thread title is A List Apart (which I visit often), but here are several other web development related sites I frequent:

Eric Meyer
Web Standards Project
Molly E. Holzschlag
Dave Shea
CSS Zen Garden
Khoi Vinh
Robert O'Callahan
Brendan Eich

There are a lot more great sites out there, but that's a start.

[Falcon]

In reference to that ALA article on forms:

I much prefer solutions that don't require JavaScript for basic styling. The <dl><dt><dd> model seems to be the prevalent semantically correct model for forms. (My university's web team uses it, phpbb uses it, it's what we use on RN, etc. At first it seems like a bit of a stretch of the term/definition structure, but when you think of "name" as the term and the definition of name as the name you enter, it makes sense. Name/value pairs have also been recognized as a valid, semantic use by the W3C.) Either solution, inline-block or the float model hack for IE, requires a hack, so to me it's really the same except that one can be done with pure CSS and the other requires JavaScript as well. Firefox, Safari, and Opera handle RN's current method without hacks, only requiring <dl><dt><dd> structure and a few lines of CSS for styling, so a conditional stylesheet for IE (with a couple of additional lines of CSS for the forms) seems like the best compromise to me. I'm not a huge fan of "code forking", but IE is still way behind the other big three and needs to catch up. And then all of the people using older versions of IE need to upgrade (that is if IE8 actually fixes most of these problems). Which probably won't happen until they switch to the version of Windows that comes with that version of IE by default... Which means we'll be stuck with the old versions for several more years... Some days I hate web development.

However, RN's forms can definitely use some "prettifying" and some better styling, and the rest of the interface is in dire need of some usability improvements as well, which is what I'm turning my attention to soon. This weekend is an RN weekend for me, so I'll have my head stuck in the code and be frequenting the forums. =)

If there's something you're wanting to do with the forms that the current code is making extremely difficult or impossible, let me know and we'll work it out. I'd also be very interested to hear your thoughts on what the form layout should look like and the changes you're making to your forms currently. Have you run into any usability issues while using RN? Anything that would allow you to get things done more quickly and easily?

[shadendorain]

Which means we'll be stuck with the old versions for several more years... Some days I hate web development.

Even with standards available, it still comes down to deciding what you personally think is the lesser of evils. I feel like javascript is an acceptable "platform independant" solution to browser compatibility issues but I can see how a purist would balk at it. The problem with being a purist is that it means having to take all the good AND all the bad from whatever it is you're trying to use. Hybrid solutions allow you to make up for the failings of one language by using the strengths of another one. Forms are the exception to the seperation of form and function that CSS tries to achieve. Most of the pure CSS solutions seem like just as much of a hack now as using tables for layouts in HTML was 10+ years ago. The only difference is that CSS purists have the W3C standards to wave around as proof that their hack is better than the old hack. In other words, I'm okay with agreeing to disagree because it's really just personal preference.

I think with RN it's that the forms are not easy on the eyes. I spend a lot of time scrolling up and down through some of the bigger forms trying to find an option. It'd be nice to see the fields grouped by type with the required fields closer to the top and optional information farther down. It took me a few tries the first couple of event creations to figure out what all the required fields were before I could finally submit an event. Some the labels are also either too long or too confusing. For example, "Should this event have signups?:" could probably be more easily undestood as "Enable Signups:". I'm still not sure what the option "Is the next event already set up?:" means.

In my particular situation, I'm the admin of Raid Ninja (and our entire website) but I'm not the end user. I can see all the flexibility inherent in what you've created but I have a feeling that some of my users will not understand how they can take what RN has and adapt it to their needs. I want everything to be clear and concise so even the really unimaginative and technically declined can still get how cool (and adaptable) RN is. I feel like the female version of Steve Jobs for my guild at times. I spend a lot of time trying to get them to understand how cool some new bit of technology is and feeling like they can only see it for it's basic functionality.

[Falcon]

Well, JavaScript really isn't as much of an issue to me now as it used to be. I prefer to use CSS for all of the presentation and JavaScript for behavior and want the application to be usable without either, which is where my issue comes in, not with using JavaScript. And indeed, a lot of the things we do for presentation in CSS 2 are hacks because we're abusing the float model to be used for things it was never initially meant to be used for. CSS 3 will help fix just about all of that once we can use it, and JavaScript is nice to emulate that behavior in browsers that don't support those properties; it can just be a mess to maintain between browser versions. Maintainability and usability are the two most important issues to me, so if we can find a solution that wins at both I'll be glad to use it, JavaScript or not. If we find an elegant solution that uses jQuery and is still usable with JavaScript and/or CSS turned off then I'm down. I think most users will have JavaScript on these days but I'd still like the entire app to be usable with it off. So, I'd like to be a purist, but I'm aware that the currently available version of CSS is lacking some necessary tools, and I'm fine with using JavaScript to fix that as long as the app isn't broken for anyone when JavaScript is turned off.

A lot of those interface issues you described came from a lack of time for polish when we were getting 2 out the door, so for 2.1 I'm taking the time to get all of those fixed that I can find. Shorter labels with description text for anything that's unclear and better grouping for form elements should help alleviate a lot of that, as well as deleting or changing purely informational items like "next event set up?" (which is just telling you if the next event is set up if this is a recurring event, but isn't very clear, obviously =P) away from form elements to pure text. Also, we'll be getting rid of the information overload for normal users on the signups page. Admittedly, Ferby and I are a bit out of touch with the interface because we don't get to use the app like a normal guild would anymore, so I'm in desperate need of feedback on interface issues. You guys who use the system a lot need to bring things to my attention, and I really appreciate your feedback, because I know there are plenty of things that could be improved but I don't always know what they are. You won't hurt our feelings, and feel free to push back if I don't understand at first. I'm pretty flexible. We're just trying to make RN the best it can be. A lot of the interface issues are pretty apparent to me, but there are bound to be ones that turn up from repeated use that I can't see. So you guys have to be my eyes. =)

As for the form elements, let's play with them a bit. The one failing of the <dl><dt><dd> structure I can see is that it would be harder to style an entire block for the name/value pair, and an element wrapping them both would make that much more intuitive to use, but I think it's still possible to achieve the effect in the ALA article with the <dl><dt><dd> structure. I would be fine with some kind of <ol><li> structure also. In fact, an <ol><li> structure with a <div> for each the name and the value may be the most flexible of all, even if it is a bit less semantically pure. I think we could get away with either of those without using any JavaScript for styling, especially since Firefox 3 has support for inline-block. However, I think it's more the logical grouping and ordering that you're having an issue with, and I completely agree. So I'll play with both structures and see which leads to more flexible styling, and then I'll fix the other issues. Sound good?

[shadendorain]

Sounds good to me! I realize some of the issues are obvious so I'm cool with waiting to see what you come up with and then adding input later. I did manage to get my templates done and now I've started going through these interface issues just to clean it up for the little idiosyncrasies of my own guild. Some of them are just resistant to change and others are boggled by it so it's easier for me to make it to their expectations then try to get them to understand a new system. I just finished a 5 hours stint of upgrading our site this weekend and I've got another 3 or 4 hours of testing a new DKP system before I do another big push next weekend (ugh) but after that I'm hoping to be able to get your latest stuff from SVN and play with it.

I've been a fan of javascript + ol/li styling ever since I needed to do a big drop down list menu for some clients who wanted to be able to add/remove items frequently. I found an article on htmldog.com (http://www.htmldog.com/articles/suckerfish/) and really liked how flexible it was but also that their intern could understand the structure well enough to make the minor changes they needed. I guess I'm a bit of a curmudgeon for it, but I think people who browse the web with cookies and javascript disable should just take their tinfoil hat and go sit in a corner by themselves.

If you're going to start working on the menu system any time soon I've got some comments on that as well. I don't like how Admin Panel and User Options take you to pages that are essentiall just menus. I also would like to have all the user options available on every page. For example, if you go in to Manage Characters, you can't get back to the signups page without first going back to the User Control Panel. I'd like the user area to be more like the admin area, where every option is available on every page.

[Falcon]

Okay. I'll do my best to get SVN ready this week. The raid interface needs some work right now, so I wouldn't suggest upgrading just yet, but I'll give you a heads up when it should be good to go.

Also, we currently have the entire menu (both user and admin) available on every page in the latest SVN build.

[shadendorain]

I have a test site so I can try things out and figure out integration before doing anything to our live site. I've been a software tester for 6 years. We QA types don't do anything hastily when it comes to releases.