Updating event-template.html

[leonelgalan]

• I think we should update the event-template to use better markup (think semantic), possibly using a framework like foundation or bootstrap. This will make the event page responsive, and hopefully easier to maintain or edit.
• Heavy use of inline styles
• Placeholders like "(insert date)" didn't tell what format should I use, I had to look in other events how everybody else was doing it.
• The template makes reference to a rg-header.psd which I believe is no longer necessary because the addition of web fonts
• The Facebook like button, was using an old API
• The template should have a sample team member and a sample sponsor, instead of information from a previous event
• We should suggest using target="_blank" for external links (Probably not the best idea, we won't do this one)
• Comments on Google Analytics would be nice, I left it untouched for the event I'm organizing, but I didn't know.

I just want to touch base, and see if this is something that we are interested in pursuing this and if there is more people interested in collaborating.

[keikoro]

Just butting in on target="_blank": please don't - it's really user unfriendly. I know it's meant to help (I guess?) those who don't know they can open links in new tabs/windows, but what it really does is take any choice away from those who'd like to decide for themselves on how to open links.

[keikoro]

Apart from that, I think it's a good idea to update the template! 👍 (I threw out quite a few bits of the current one when I created the page for our Vienna event because I didn't find them very usable...)

[leonelgalan]

Fair enough, I wasn't completely sure about that one. I'll start this
weekend, maybe create a second template to get feedback on it.
On Aug 9, 2013 5:29 PM, "Kay" notifications@github.com wrote:

Apart from that, I think it's a good idea to update the template! [image:
👍](I threw out quite a few bits of the current one when I
created the page for our Vienna event because I didn't find them very
usable...)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/194#issuecomment-22424454
.

[keikoro]

Sounds like a good idea! It's also what @lindaliukas suggested back when I said I might rewrite it (which I then never came around to, ahem).

[leonelgalan]

I've done some progress (not recently) on the template: make sure you see the source code (we want cleaner markup) and in different screen resolutions: http://leonelgalan.github.io/railsgirls-event_template/

I'm going to keep working on it this week.

[bazzel]

I've been playing around with the event template. If you like, you can take a look at http://rg.patrickbaselier.nl/event-template.html to view the result.

I've used middleman for this since I don't like html so much, but I love haml, Sass and compass.
I switched to Foundation 4 (it uses only the grids module) which makes it responsive (take a look here: http://www.responsinator.com/?url=http%3A%2F%2Frg.patrickbaselier.nl%2Fevent-template.html) and it has vertical rhythm (http://24ways.org/2006/compose-to-a-vertical-rhythm/). Code can be found at https://github.com/bazzel/railsgirls/tree/feature-foundation5 and is located in the source folder.

I only worked on the event template, since this both has impact on the markup (although I tried to keep it as close to the original as possible) but also on the structure of the application and the deployment process. It needs some more work to restructure the home- and other pages.

Hope you like it and if you consider using this, just let me know if I can be of any help.

[leonelgalan]

I like what you did here, except for HAML and Compass. I don't like HTML too (I'm using SLIM more often than HAML), but it introduces has a learning curve to steep for some. Compass, shouldn't be required.

Minor things I noticed:

• The menu could do something fancier when viewed on mobile
• The HTML could use less divs and be more semantic
• The grid could be semantic.

Maybe we can chat, and make the best of both solutions a single, stronger solution that can be reconsidered by Rails Girls.

[keikoro]

Are there any good/easy to understand tutorials for HAML? (Funnily enough, yesterday was the first time I opened a HAML document, and now I'm actually stuck editing it...)

Otherwise I'd also stick to HTML because it's what most people know!

[leonelgalan]

Both slim and haml have their better documentation in their sites: http://slim-lang.com/ & http://haml.info/. They are not very good, but it's there! While doing slim, I found this to be useful: http://html2slim.herokuapp.com/

[bazzel]

@leonelgalan: I agree with your objectives. Although pre-compressing can save a lot of time and can bring structure, it does introduce a learning curve. This also counts for Sass (and Compass), and currently I haven't thought about how to tackle this. Maybe a template can be produced using pre-processing tools and users are presented with a processed version?

I intentionally didn't touch the existing markup (or as little as possible), but I agree, this can be more semantic.

Your suggestion about combining our approaches sounds nice.

[abelards]

I think this might be related to #557 since we could use Jekyll to generate most stuff.
This would give an HTML template with some {{liquid}} {{tags}}
How would you feel about this?