Designing a hundred checkboxes

I am designing a registration page where a user selects newsletters they would like to join. There are literally hundreds they could choose. It is medical and I think I will simply structure it in a hierarchy of topic and sub topic.

example:


[] cancer
  [] lung
    [] stage 3
  [] throat
  [] brain

I have a two fold question really. One, because there are so many options, should I use a CSS div hide scheme. Where say the 25 main topics are displayed and if they check say cancer CSS will prompt the sub topics under cancer to appear? Is that the best way? Second question is do I hard code all these topics into the page or do something sophisticated with a database? thanks!!

The only browsers which don’t support those mentioned pseudo’s are IE6-8 (9 does support them) therefore supporting browsers will give the effect even when scripting is disabled (which is more than jQuery does). As for IE6-8, the “emulation” simply requires a small unobtrusive script (less than 10 lines) - which does the same as jQuery with less bloat and KB usage. Why use CSS3? Because JavaScript isn’t always available to everyone and they shouldn’t be punished for having it disabled, it puts less strain on rendering (CSS is less impactful than JS), and it doesn’t need any third party library (bonus). I would have thought you of all people would prefer the least obtrusive method and I can’t actually believe your promoting jQuery over CSS (oh and it’s not “pseudo-CSS3” it’s part of the specification). :slight_smile:

You can use sibling selectors alongside pseudo’s. All you need is a checkbox with subsequent ones following it to have a class name that effectively “groups” them, then you just need to set the :checked state with a sibling selector (for those of the matching class) to make them visible. Essentially… upon the thing being checked, the adjacent bit will filter through those checkboxes who share the same parent (and the class mentioned) to apply the effect. It works, it’s legal and it’s semantic.

As for the anchor one, you don’t need anything of the sort. Fragments are fairly simple, you have an anchor that links to (say) index.html#dothis and you have a DIV somewhere in the page that has an ID with matching selector for div:target. Thereby when the fragment (#dothis) within the index.html is “active”, the div with the ID that matches the fragment can be made visible (or you can style the thing to match your requirements for when the state is active). The whole point of :target is it instigates an action on whatever ID matches the fragment, inheritance has absolutely nothing to-do with the effect, it’s a one element trigger. :slight_smile:

If you have 100’s of categories of newsletters grouped into multiple layers with several newsletters in each category I would recommend using a database to store the category hierachy using a nested set model.

Each newsletter is then linked to a category in the database.

The advantage of using a database, especially with 100’s of categories, is that you can then build html forms where the person maintaining the catalogue of newsletters can easily add/edit/delete/move categories and newsletters without having to know any html, javascript, server-side or database languages.

As far as retrieving the catalogue info goes, you can extract the relevent records from the database for the particuar web page and generate the html dynamically on the server before sending it back to the user’s browser.

it’s still only a theoretical solution.

(if) the page is dynamically created on server side, or the option chunk is a server side includes, which were the main solution mentioned, there is no reason to say that you rely on client/server communication taking more additional time (other than to actually get the page of course :slight_smile: ).

also AJAX is not a solution, and so any other javascript solution. you don’t target an enhancement here, you target a feature. relying on javascript means some users will lose the feature.

if you go javascript route, which is not a real solution here, why bother using some pseudo-CSS3. i’m sure that by now jQuery looks better than any problems you have to take account for with pseudo-CSS3 :slight_smile:

well, the answers are simple:

  • can you/will you be able to use a server side language like php to generate the options dynamically?

  • can you/will you be able to use server side includes on the server?

if not, hard coding is all that’s left.

sure, there are other techniques like AJAX, XML processing, but these involve javascript. unless you want to restrict possible newsletter users to only those allowing javascript code to run in their web pages, you can’t really think of these techniques.

but hard coding the options in the page doesn’t necessarily mean that the work has to be a tedious hand made process. you can use any number of scripting, query or programming languages :), to generate the html from a specific data source, like a database, an XML file or a spreadsheet.

Actually, there is a pretty good solution to what you’re looking for… CSS3.

CSS3 contains two pseudo’s which can allow the showing and hiding of information based on decisions made by the user. These are :checked and :target. While both will need a couple of lines of JavaScript code to deal with IE’s lack of CSS3 support (it can be done unobtrusively) it makes more sense than to rely on client/server communication which takes additional time. Checked basically allows you to assign stylistic CSS code upon a checkbox being put into a checked or unchecked state (so you could hide children by default and show them only when the box is checked) and target works on a link basis where you set a link to an anchor fragment (like #checkbox1) and upon that being selected the subsequent children will be visible. Checked is the best route if you want multiple sets of child elements visible at any one time (so it expands and contracts), but :target would be the better option if you intend on guiding your visitors through a series of choices (so if you broke the form down into a “check next to continue” style wizard with the options appearing in unison). Both have pro’s and con’s but it’ll do the job. :slight_smile:

no, i’m not promoting jQuery :slight_smile: also, i’m not promoting jQuery over css :slight_smile: i’m suggesting jQuery over pseudo-CSS3.

my reasoning: you want a beginner to apply CSS3.

  • to start with, he would have to know how to make some UAs “understand” CSS3.
  • then, he should learn what CSS3 implementation each UA has (no UA is born the same when it comes to CSS3).
  • and finally how to take care javascript way of those UAs and/or UAs features that don’t know CSS3 at all.

so, instead of doing all that, wandering eternally between conflicting specs and implementations, to get the job done in the way you suggested, jQuery would’ve been the right choice for him: it would take care of both the effects and cross browser issues and get the job faster.

but…

css3 is good. for those experimenting. for those enjoying an already high css understanding level.

otherwise, plain ol’ good css2 will do perfectly for this task. no javascript, not even for effects. why? 'cos it’s a feature that has to be always available: options to choose from. it’s not an enhancement one: rounded corners, fading…

and i said:

  • start from categorizing
  • build a data source for them. Kalon suggestion is actually a very good one :tup:!
  • generate the markup based on the data source:
    [LIST]
  • using code to make static content to add manually in the page or use as server side includes
  • using server side code to create an active and dynamic page
    [/LIST]
  • put them all in a page and serve them all at once
  • use the previous categorization with css styling to offer a quality user experience

surely not. if you are not happy with it, you can always improve it.

i would also concentrate first on finding and choosing the right css solution for me for letting only a selected content visible at a time, to improve the user experience.

than i would test it using only a small amount of those options.

when all things seem to be final about all of the above, i would find a solution to store and keep these hundred options in a data source from where i can generate html code for them in an automated way.

I’m leaning on static because although it is monotonous, it is easiest. is that a poor decision?

I would probably want to keep them on the screen just for simplicity - but you don’t need them to be in a vertical list from 1 to 100.

If you use <fieldset>s to group the items into appropriate groups, then within each <fieldset>, have a <ul> list of checkboxes, but have the list running horizontally so that it doesn’t take up as much screen space.

Checked basically allows you to assign stylistic CSS code upon a checkbox being put into a checked or unchecked state (so you could hide children by default and show them only when the box is checked)

Checkbox inputs… can’t have children. I can’t see how this would work AND be legal?

The other one, with the anchor, sounds like you need HTML5 which lets you wrap anchors around blocks.

css has nothing to do with where the html markup comes from :slight_smile:

as you’ve said, you are to solve a css part and an html part, both presenting with a little challenge.

the html part: can be

  • static: html static markup

  • dynamic: html markup generated at server side using a programming of some kind from a data source of some kind, and served by means of dynamic web pages or server side includes. for this you need to decide:

[INDENT]- which to language to tackle and head to the respective sp forum :slight_smile:

  • which data source you think you can handle[/INDENT]

the css part: you need to figure out a solution that is user friendly, attractive and efficient. leaving hordes of option will not make anybody sign up for any newsletter. first you need to make categories, subcategories and so on. then you have to css those categories and subcategories using tabs, accordions or other show&hide css solutions.

I see, should I put the options into an array type structure? Seems complex to do that dynamically with css hide/show divs. I’m beginner at PHP.

thanks!

Should I hard code or use maybe an XML file? i just really don’t know how to organize this.

25 main topics are still too many. do you really think you will, as a user, find any pleasure selecting newsletters to join in such a vast option field?

you need further categorization. and yes, keep it to the minimum, hide/show what’s needed. accordion, tabs, something on these lines.

there isn’t really a need for a database. and again, you really think you, as a user, would wait, after choosing a category, for the page to make a call back to server and retrieve data from a database, for the server side coding to send that data back to you and for the browser to show it to you? only to find out the list didn’t have anything you wanted as a user and have to go through all that all over again? :slight_smile: