That's really interesting about how you learn. I've enjoyed your periodic posts on the topic and I'll probably be even more interested now I'm actively learning myself. The thousand small applets each doing a thing sounds like a really good approach.
And really good point about programming versus typing in code. When I used to program back in the 80s, I did type a lot of code from magazines, but I always understood which bits I could change if I wanted to, silly things like giving myself 100 lives instead of 3 (I was a kid, after all), but it helped me to understand what I was typing. Nowadays, with online or book-based courses, they often only tell you whether you got the code exactly word-for-word right as the course author intended, so you have no idea if you just made a variant but still functioning program. CodeAcademy tries to be a bit fuzzy, but it is kind of buggy so often it was giving me errors for things I knew were right (just not identical to the suggested solution) or accepting absolutely any nonsense as valid code.
The custom colours thing: those options exist, but I didn't expose them to the end user. I made lots of options for layout designers exactly as you describe, but more experienced people agreed at the time that which bits have custom colours is a design decision, not necessarily a user option. Exposing at least some of that as an option where you can just tick a box in the wizard is technically doable, but I've made the system really quite flexible for designers, it wouldn't be very straightforward to translate that into nice simple tickyboxes. Basically you can make pretty much any element (or several) of the page have custom colours if you want to, so it's hard to condense that into wizard options.
What might work for you personally is a theme layer with the following code: set custom_colors_template = "%%new%% .entry .footer { background-color: %%background%%; } %%new%% .entry .footer a { color: %%foreground%%; }"
You can't do this with CSS alone because you need database access to be able to decide which person should display in which colours, it has to be in the code. Which is another argument for why it should be in the wizard, in some ways.
What exactly do you mean by "colourcode a custom group"? Do you mean, instead of having liv be one colour combination, and lethargic_man another, you can tie the colours to reading list filters, so everybody in the "SF fans" filter is one set of colours and everybody in the "random DW people" filter is another set? That would be a lot harder because it would require me to completely recode the way that custom colours work, but I can certainly see how it might be a useful feature when I get a bit more confident at programming complex things.
Miscellaneous. Eclectic. Random. Perhaps markedly literate, or at least suffering from the compulsion to read any text that presents itself, including cereal boxes.
(no subject)
Date: 2013-05-21 03:01 pm (UTC)And really good point about programming versus typing in code. When I used to program back in the 80s, I did type a lot of code from magazines, but I always understood which bits I could change if I wanted to, silly things like giving myself 100 lives instead of 3 (I was a kid, after all), but it helped me to understand what I was typing. Nowadays, with online or book-based courses, they often only tell you whether you got the code exactly word-for-word right as the course author intended, so you have no idea if you just made a variant but still functioning program. CodeAcademy tries to be a bit fuzzy, but it is kind of buggy so often it was giving me errors for things I knew were right (just not identical to the suggested solution) or accepting absolutely any nonsense as valid code.
The custom colours thing: those options exist, but I didn't expose them to the end user. I made lots of options for layout designers exactly as you describe, but more experienced people agreed at the time that which bits have custom colours is a design decision, not necessarily a user option. Exposing at least some of that as an option where you can just tick a box in the wizard is technically doable, but I've made the system really quite flexible for designers, it wouldn't be very straightforward to translate that into nice simple tickyboxes. Basically you can make pretty much any element (or several) of the page have custom colours if you want to, so it's hard to condense that into wizard options.
What might work for you personally is a theme layer with the following code:
set custom_colors_template = "%%new%% .entry .footer { background-color: %%background%%; }
%%new%% .entry .footer a { color: %%foreground%%; }"
You can't do this with CSS alone because you need database access to be able to decide which person should display in which colours, it has to be in the code. Which is another argument for why it should be in the wizard, in some ways.
What exactly do you mean by "colourcode a custom group"? Do you mean, instead of having liv be one colour combination, and lethargic_man another, you can tie the colours to reading list filters, so everybody in the "SF fans" filter is one set of colours and everybody in the "random DW people" filter is another set? That would be a lot harder because it would require me to completely recode the way that custom colours work, but I can certainly see how it might be a useful feature when I get a bit more confident at programming complex things.