Closed Bug 962509 Opened 10 years ago Closed 10 years ago

Simplify the HTML for Teaching Kits

Categories

(Webmaker Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fuzzyfox, Assigned: fuzzyfox)

References

()

Details

(Whiteboard: [workweek]teachingkit, mvp)

Attachments

(1 file, 1 obsolete file)

Idea: minimise the amount HTML needed to create a Teaching Kit, thus reducing the time it takes to create.

* Reduce CSS into a single <link> tag by consolidating into a single file
  * Even a main, and then including the rest w/ @imports
* Remove HTML adding visual flare, and move it into the CSS
  * e.g. vertical lines for the agenda blocks
* Make blocks more resuable by having stying them with class selectors not IDs.
* Simplify and reduce code for layout
  * Rely more on heading level than section tags, make use of HTML5 tags like <header> and <main>
Assignee: nobody → williamd
Whiteboard: [experiment][webmaker workweek] → [experiment][febworkweek]
* We're discussing ways to simplify the kits at [workweek]
* + Cassie
Summary: Simplify the HTML for Kits → Simplify the HTML for Teaching Kits
Whiteboard: [experiment][febworkweek] → [experiment] [workweek]
:brett
noted... this is very similar in principle but w/ a focus on kits. If the design for kits is due for a revamp to fit in w/ makerstrap then this should be marked as dupe and I can add the additional few ideas around this (not yet made it into digested form) to that bug. Otherwise this is still valid (in my eyes) due to being around the kit designs.

:OpenMatt
I was trying to stick w/ kits for terminology as this also applies to activity kits too... Should change the subject back?
Status: NEW → ASSIGNED
[Moving this from experiment to something we want to deploy]

New considerations:
  * Where do we ship to?
  * How best to we implement this on wm.o without breaking existing kits?
    * The new kit implementations use a different HTML and CSS structure and are *not* backwards compatible, however should be easier to make later iterations backwards compatible without too much pain.
  * Who needs to review these changes?

Version to ship: https://github.com/fuzzyfox/slimkits/tree/v2.2
Diff from exiting version: https://github.com/fuzzyfox/slimkits/compare/v2...v2.2

Kits to implement:
  * kit.html
  * activity.html
  * event.html
Whiteboard: [experiment] [workweek] → [workweek]
Kate / Gavin – can you guys contribute thoughts here? Fuzzy, you'll ultimately want to flag either of them to review. Thanks for your work on this!
Flags: needinfo?(kate)
Flags: needinfo?(gavin)
cool beans, the design of the kits has not been changed for these (w/ the exception of the event kit). Just the HTML and CSS.
Attachment #8374984 - Flags: review?
Since I am sprinting on login this week I unfortunately won't be able to get to this this week :(

Maybe Gavin can look at this, or if it's ok to wait 'til next week, I'll get to it ASAP Monday.
Blocks: 973927
Component: Community → General
Comment on attachment 8374984 [details]
https://github.com/fuzzyfox/slimkits/tree/v2.2.1

>https://github.com/fuzzyfox/slimkits/tree/v2.2.1
Attachment #8374984 - Attachment description: https://github.com/fuzzyfox/slimkits/tree/v2.2 → https://github.com/fuzzyfox/slimkits/tree/v2.2.1
Marking this as a blocker because we need William's simplified kits reviewed and on http://webmaker.org/teach-templates before we start training (we're launching janky alpha version for 100+ people mid March).

AFAIK This is just a code review and the go ahead for me to swap out the code in:

https://mozteach.makes.org/thimble/make-your-own-teaching-kit
https://mozteach.makes.org/thimble/make-your-own-teaching-activity

Or, am I misunderstanding Will?

Can we get this in ze queue please?
Severity: normal → blocker
Flags: needinfo?(williamd)
Fuzzy, Kate is back today but probably coming back to a long list of to-do's. You should flag either her (if you can wait) or Gavin for a review on your attachment. Flagging them specifically will make it show up in their dashboard queue, making it much more likely to happen.
Noted, deliberately not assigned to anyone in particular at the moment till after the kit redesign meeting later today as we may deem this intermediary step as not needed, if we think the redesigns can be done in time as to satisfy the needs of the training platforms first run, etc... at an MVP level.
Flags: needinfo?(williamd)
I'm going to clear the needs info for now since you and Cassie mentioned there were more decisions needing to be made, but if a review or more questions come up following that please re-flag me so I notice it. Or ping me on IRC. I am now back from vacation/caught up :)
Flags: needinfo?(kate)
Hi Kate - here is the pad https://etherpad.mozilla.org/teaching-kit-mvp determining redesign MVPs from our meeting on Friday, but I'll leave it to Cassie to have a 1:1 with you guys on this to get you properly up to speed. From the Teach the Web end of things, we'll have more specific timelines for you guys on when kit redesigns are needed for the community by mid-week. 

Yay!
Whiteboard: [workweek] → [workweek]teachingkits, mvp
Whiteboard: [workweek]teachingkits, mvp → [workweek]teachingkit, mvp
Sounds like I'll need to have that 1:1 to get up to speed. Clearing the needinfo for now...
Flags: needinfo?(gavin)
Attachment #8374984 - Flags: review? → review?(kate)
Comment on attachment 8374984 [details]
https://github.com/fuzzyfox/slimkits/tree/v2.2.1

This is looking awesome, just a couple of things: 

1.Any reason you have a separate style block?
https://github.com/fuzzyfox/slimkits/blob/v2.2/remix-kit.html#L8

2.less/style.less

- Don’t @import normalize and font awesome, that will add extra HTTP requests. Either install these external assets with bower (preferred) or check in the files. You should import them as Less at compile time. To import less as css see http://lesscss.org/features/#import-options-less

- When importing Less, you don’t need to include the ‘.less’ extension in the file path.

3. Mobile styles
- Personally I don't really like using max-device-width, I find that it’s  less reliable/more annoying to test/unnecessary. Just use max-width
- Can you use the makerstrap/bootstrap breakpoint(s) instead of a hardcoded value?
-This would be a lot more refactoring so don’t worry about it for now if you need to move forward on this, but I should mention the way bootstrap/makerstrap is written is mobile first — i.e. the default style is for mobile/every size, and styles for larger screens are added with min-width media queries. Additionally, it tends to be easier to maintain mobile/desktop styles if they are mixed in together:

e.g.

right:
less/header.less
header {
  height: 50px;
 @media screen and (min-width: @screen-sm-min) {
    height: 100px;
  }
}

wrong:
less/header.less
header {
  height: 50px;
}

less/mobile.less
@media screen and (min-width: @screen-sm-min) {
  header {
    height: 100px;
  }
}

One more minor dev detail - consider using a static server (grunt devserver) if that’s all you need, or a framework like connect/express that will handle reading files/setting the correct mime type etc.
https://github.com/fuzzyfox/slimkits/blob/v2.2/server.js#L1
Attachment #8374984 - Flags: review?(kate) → review-
Sorry, the wrong example should be

less/header.less
header {
  height: 100px;
}

less/mobile.less
@media screen and (max-width: 640px) {
  header {
    height: 50px;
  }
}
(In reply to Kate Hudson (:k88hudson) from comment #17)
> Comment on attachment 8374984 [details]
> https://github.com/fuzzyfox/slimkits/tree/v2.2.1
> 
> This is looking awesome, just a couple of things: 
> 
> 1.Any reason you have a separate style block?
> https://github.com/fuzzyfox/slimkits/blob/v2.2/remix-kit.html#L8

This is more an example of usage rather than something to be implemented. I guess a filename change would be better for this, along w/ some better context in the readme

> 
> 2.less/style.less
> 
> - Don’t @import normalize and font awesome, that will add extra HTTP
> requests. Either install these external assets with bower (preferred) or
> check in the files. You should import them as Less at compile time. To
> import less as css see http://lesscss.org/features/#import-options-less

So import these to be compiled so that the frontmatter (<head>) of the kits remains the same, but all the code is in the same cssfile (after compile)?

> 
> - When importing Less, you don’t need to include the ‘.less’ extension in
> the file path.

My bad, learn something new everyday.

> 
> 3. Mobile styles
> - Personally I don't really like using max-device-width, I find that it’s 
> less reliable/more annoying to test/unnecessary. Just use max-width
> - Can you use the makerstrap/bootstrap breakpoint(s) instead of a hardcoded
> value?

Can do, would use makerstrap as a reference I'm guessing to pull this off for the time being.

(Idea of this bug is just to simplify existing template/design code, not a redesign)

> Additionally, it tends to be easier to maintain
> mobile/desktop styles if they are mixed in together:

#gotit

> One more minor dev detail - consider using a static server (grunt devserver)
> if that’s all you need, or a framework like connect/express that will handle
> reading files/setting the correct mime type etc.
> https://github.com/fuzzyfox/slimkits/blob/v2.2/server.js#L1

Good tip, thanks ;D I've actually switched to using http-server installed globally for testing now. (Good/Bad/Ugly?)
Looking good!  A few suggestions to take a look at
Attachment #8398657 - Flags: review-
Attachment #8374984 - Attachment is obsolete: true
Attachment #8398657 - Flags: review- → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Severity: blocker → normal
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: