@media for email

Screenshot of our example code with @media-queries

Screenshot of our example code without @media-queries

When you send a newsletter or campaign you can’t predict how the user’s email client will render it as you don’t know what client the receiver has. This means we can’t create multiple versions and decide up-front which version we send to the which client. Luckily we can control the HTML rendering with CSS @media-queries on supported clients. Support of this is good on iOS but behaves somewhat unpredictable on Android Mail, but the good thing is that clients that don’t support them will just ignore them. By using @media-queries you can target certain css-rules that only should be applied when the size of the dislay is smaller then a specified size (there are other options too, but for simplicity’s sake I will stick to the size for now).

I’ve made a gist of the code I used for the example above. This example shows how you can use @media-queries to adjust your e-mail to the screensize of the iPhone.

Controlling the preview

Another trick I like to mention is a solution to control the preview of an email. The mentioned studies confirm that the preview functionality of email clients is very important in the decision wether a receiver will read your email or not. This See the example below:

As with everything web-related, the content remains the most important reason for a receiver to read your newsletter or not. But now it’s possible to do a lot of cool stuff. I mean hey, we can even use box-shadow in emails on the iPhone.

Some font embedding history

• Back in the 80ies fonts were bitmaps because they were fast to render
• In the early 90ies there were font wars between Adobe and Apple (later joined by Microsoft)
• Finally PS-fonts were defeated by Apple’s/Microsoft’s truetype fonts
• Font embedding was possible in NN4 by .pfr fonts
• In IE4 MS solved the problem with @font-face declarations in css with .eot fonts

Font embedding now

• You have to supply the font in 4 different formats (.woff, .eot, .ttf and .svg)
• After 17 years, this is the best way we came up with to support fonts? See the slide on how to embed the font
• Font loading mechanisms are very different across browsers
• Current Opera’s seems to be horribly broken with @font-face
• IE6, IE7 and Opera have very bad fallbacks

Optimizing fonts for embedding

• Reduce the number of glyphs
• Chop fonts up in several glyph-ranges and use unicode-range, it’s not very well supported though
• Send the font gzipped to the browser
• You could remove hinting, but this makes rendering go bad in windows GDI
• Using postscript outlines improves windows GDI rendering

Font loading

• IE8 has terrible font-face loading mechanism
• Supply the font in-line before any css/script tags for IE8
• Or use google webfont-loader
• Font-size adjust helps us to sync sizes of the fallback font with our font

Bottom line

• Serve at least EOT & TTF fonts
• Avoid unnecessary downloads
• Show content quickly
• Make fonts small

• You need to give devs/users the tools and resources to grow
• Initial contact whould be extremely simple
• A good first impression should answer:
  • What is this?
  • What can it do for me?
  • Where can I go to learn more?
• The user should never have to ask for help in the getting started tutorial
• After initial contact, the user should have multiple internal and external channels to ask questions
• Monitoring your community is very important
• Treat every use as a future contributor, because the can be
• Follow up with your large users, contact them and make sure their issues are being addressed
• Make sure your users feel like they are being heard
• Good API documentation is critical
• You need to provide a larger structure so your users understand how things work and can learn
• Be transparent in your process
• Test everything with a clear process
• Fix bugs according to a defined process
• Open up the roadmap decisions so people can participate and contribute
• Support your users, track your users, help them grow and flourish

• He curates very cool web-graphics on creativejs.com
• Looking at awesome visuals is nice, but creating them is even better
• Particle systems are easy and cheating goes a long way
• Drag, gravity and collision detection can be done in a pretty simpl way
• One particle is just pointless
• Using additive blending can be used to create a lot of effects
• Don’t worry about screwing things up
• Share the things you create

New input types/attributes and elements

• Some of the new input types in HTML5: date, range, search, number
• Mobile forms are very hard to use, the new HTML5 input types can give dedicated controls for certain input types
• New form attributes: autofocus, autocomplete, formaction (and other form specific attributes), spellcheck and placeholder but there are still some browser inconsistencies
• mozactionhint can change the “next” button of mobile keyboards (Mozilla only at the moment)
• Datalist entries make autocomplete/selection a breeze

Form validation

• required attribute for required fields
• Validation by a certain input type like email (currently only works with us-ascii characters)
• More advanced validations by regular expressions are possible too, but they accept empty strings and give no hints about the format on error
• Custom error messages still have to be set in JS though and they break the checkValidity function in javascript
• There is a invalid event which seems consistent in all browser and you can use it to show the validation messages
• Validation happens on pageload too, but nothing has been filled in at that point, so it’s currently a bit useless
• In Mozilla there is the ui-moz-invalid which remedies the validation-on-pageload issue

Styling

• You can style the placeholder with the :-PREFIX-placeholder pseudo, but you can onlys style some properties (in webkit at least)
• To style error messages there are a lot more pseudos like :invalid

Can we use it now?

Robert thinks so, but cautiously it is also possible to use polyfills if necessary, but those need to be applied cautiously too

The 2012 workflow

Webdevelopment-tools

• Learn about them and use them. Not just debuggers for css/js but also emulators/simulators, remote debuggers and documentation.

Version control

• Use version control everywhere, even for design.

Feature based design

• See what (browser)features we can use and deliberately make design-choices based upon their availability
• Use polyfills for functionality thas is essential for the core experience of your website
• Always use all vendor-prefixes if they are necessary. Know the css vendor-prefix lifecycle (See Divya’s slide on vendor-prefix lifecycle) and drop them if they aren’t necessary anymore
• Drop vendor-prefixes for: box-shadow, border-radius, background-clip

Pre-processors

• They make coding a lot easier with features like auto-spriting and mathematical calculations
• Incorporated in a build-script they make deployment of your assets to production very simple

Embracing specs

• Learn to love the specs, learn them by heart and make it part of your work
• If you’re proficient in the specs, submit bugs to browser vendors and participate in the working-group discussions

Divya’s sheets from her presentation can be found here: http://nimbu.in/fronteers/#intro

The process of change

• We want to our toys and we want them right now, but we’re stuggling with the adoption risk:
  • Lock-in risk: is this feature a standard?
  • Run-time risk: we want it to perform!
  • Mission or rechnical risks: we nee configurable and extensible APIs
• Evolution thrives on iteration, without regular browser updates we can’t use new features
• Solutions to stalled evolution:
  • Plan A: an evolving platfrom
  • Plan B: frameworks and compilers (polyfills, js-libraries, pre-processors, etc)
• We should focus on taking advantage of new stuff, because there will be more future than there was past
• We need checkpoints but we need to keep feeding the process of change
• We thrive on shared ambiguity: HTML doesn’t mean anything by itself, but we agree on what it means and therefor it has meaning

Web components & model-driven views

• Web components allow us to define our own elements like <x-comment></x-comment> with it’s
  own internal shadow dom, default styling and scripted behaviour.
• Model-driven views is basically templating directly in HTML. Data can be fed to these views directly from HTML or by JS

The image spec

• The gradient angle orientation has changed in the latest specs
• The element() function allows us to use an element as a background of another. This means we can use generated canvas images as backgrounds
• The image() function is a beefed-up url() function which allows us to have fallbacks for images or create an image from a color on the fly
• Other new rules in the spec: image-resolution, image-orientation, object-fit & object-position

The list spec

• We can use the ::marker pseudo-element to style the bulletpoint/number
• We can declare new counter-styles with our own glyps (very powerfull feature)

The values & unit spec

• Defines basic units in css.
• Some new units:
  • vw and vh (viewport width/height)
  • ex (font’s x-height)
  • rem (the computed value of font-size on the root element)
  • ch (with of a 0, an average character)
• calc() allows us to add units up for instance: width: calc(100% - 20px);
• attr() takes a certain element attribute and uses it as a CSS value
• cycle() cycles on each nesting

CSS4 selectors

• Table :col pseudo to style table columns
• New link pseudos like :any-link (matches visited links too) and :local-link (matches in-page links, can also match on parts of the url)
• New time pseudos :current, :past and :future
• Reference combinator: lets you follow IDREF attributes like for by using /for/

And more

• CSS variables, declaring variables with @variable $mycolor #fff and use them like this: color: $mycolor;
• CSS Nesting so we don’t have to re-declare a lot of selectors

Let’s hope we can use some of these new css features soon!

• As the web annihilates print, we want to be able to do things we can do in print
• We still don’t have a decent layout-algorithm but we have stuff like round corners, shadows and animations
• Stephen divides layouts in three types: page layout, (ui) component layout and content layout
• CSS Regions is an extension on multi-column layouts. It allows us to place elements and have content overflow into these elements.
• CSS exclusions allow content to flow in or around a shape, but it needs proper hyphenation support
• With line grids we can align placed elements according to baseline
• In frontend development we focus a lot on tools instead of looking at the problem at hand, we should be wary of just using cool features and apply zero-based thinking (what’s the absolute minimum?) and build from there.

• Semantics are tough because it’s about content, and there is no such thing as a validator for it
• Semantics are about language and meaning, we currently have 105 elements in HTML5 to mark up our content meaniningful
• In HTML5 some elements have been redefined to give them meaning (like the I or SMALL tag)
• There are 33 new elements in HTML5 (like time and ruby)
• Just because things don’t work yet, doesn’t mean we shouldn’t use them, because they will work
• The golden rule in semantics is: there is no golden rule (except you make a choice and stick to it: be consistent)
• Semantics matter, even if we may not have much use for them yet, we cannot know what they can be used for in the future

Setting things up

The setup for Google Apps is easy and straight forward. First Google needs you to verify the domain ownership to make sure you’re not trying to seize a random companies email. After that you can start your actual setup. Following the setup wizard doesn’t take too long and it feels Google has put quite some effort in streamlining the set-up process. I didn’t add any Marketplace apps as I wanted to see the bare functionality of Google Apps. And I must say that after a quick look into the Google Marketplace I’m not sure I ever will add an app from it. Don’t get me wrong, there is a lot to choose from. But most of it is poorly documented and couldn’t give me a production ready feeling. Another thing about the Marketplace that bothered me was it being full of service companies offering me to setup my Google Apps environment. But enough about the Marketplace. The setup was finished and it was time to get started with my brand new Google Apps intranet.

What I wanted

My plan was to create a start page for our company intranet where I would put the latest posts from my management Google group that I had set up with the wizard, a calendar with all the planned appointments of all the users, the personal emails of the current user that is logged in and a people finder. The first option that came to mind was using Google Sites for this.

What Google gave me

After about 10 minutes of playing with Google Sites it was clear that I wasn’t going to be able to do what I wanted. Sites is a nice addition to the personal side of the Google platform, but as a business tool it lacks depth and more importantly integration. Why doesn’t Sites work with Google Docs in stead of a file cabinet? And why doesn’t it integrate with my Google Groups in stead of having it’s own announcement page?
Creating a people finder was a similar pain in the back side. I just couldn’t find a quick out-of-the-box way of doing this. But why not? Was I asking for too much? Maybe my idea of a seamless Intranet is just not of this time anymore. I know the Intranet is changing, but I thought it was moving towards better integration between different applications.

Conclusion

Mail, Docs and Groups are easy to setup and easy to use. Sites might work for some, but don’t expect any form of interaction between Sites and other Apps out-of-the-box. Contacts works nicely when you need to find someone to send an email to, but what if I want an overview of all the people in the company?
AlthoughI feel I have only scratched the surface of what Google Apps is capable of my conclusion, for now, is that if you need low cost, scalable intranet functionality as email, collaboration and newsgroups Google Apps is the way to go. But if your intranet needs are bigger, and you want an intranet where services integrate seamlessly with one another, you’ll need to find a Google Apps development company that can build your bespoke intranet solution on the Google Apps infrastructure.
But I do see a potential problem here. Most IT Companies that claim to be Google Apps experts have little or no experience creating tailor-made software for the Google Apps platform, which for now is leading to a whole bunch of stand-alone software solutions that lack integration with the whole Google infrastructure (except for the login functionality).
Maybe it’s time for a new Google certification. The current Google Apps Certification only states that you’ve implemented Google Apps a couple of times, but says nothing of the quality or the know-how of software development.

I guess the good news is that as more companies are making the switch to Google Apps, more IT companies will start developing on the platform and maybe one day we’ll see a Google Apps Developer Certification.

1. Advanced transition functions with the cubic-bezier() function
2. Border-radius: using percentage values to make scalable circles and elipsises
3. Achieve multiple outlines on a box by using multiple shadows and the a spread parameter
4. Making pointer events pass through overlaying elements by adding pointer-events: none;
5. Adjusting tab size for code display with tab-size: 4
6. Doing cool stuff with :nth-child, :nth-last-child and :first-child pseudoselector to select elements
   with a certain amount of siblings.
7. Styling checkboxes and radiobuttons with the :focus and :checked pseudos
8. Use new CSS3 mouse cursors like cursor: none; (in games for instance) or cursor: not-allowed;
9. Create background patterns with CSS3 gradients (check out her pattern library too)
10. Position your background by using background-origin

• “Everything you’re doing just seems to be kind of a hack”, these hacks are needed beacause of decisions that someone else made
• Progressive enhancement for websites: HTML -> CSS -> Javascript
• Progressive enhancement for webapps: HTML (core content + core behavious (!!)) -> CSS -> JS -> ARIA
• Choose your layer carefully. Should a certain icon be content or should it be presentation?
• Progressive enhancement allows us to change the layers, excellent example of a user stylesheet (see the fronteers website with a hi-res user stylesheet applied)
• Typical accessibility problems:
• using the wrong controls
• managing flow / non-linear flow (for example: contextual help popping content up from another place of the html source)
• getting trapped with the keyboard

• “We are cyborgs”: a cyborg is someone who has technological extensions to his natural capabilities. We all have a smart-phone, which is such a technological extension.
• The web is to the OS what flash is to the web, because it needs the extra layer on top of the OS: the browser.
• As long as there is a browser layer, the UX will suffer.
• Make the web native by removing the browser
• Native is catching up to the web, but the web still has some advantages for the developer and user
• The web doesn’t have to be installed
• The web has easy deployments, but native is catching up with appstores
• The web has universal access (from anywhere from any device), native has problems here
• The web always has up-to-date data, native is catching up by synching as always connected is still a pipe-dream
• We make things for people to use. So we need to worry about UX, not about our needs.
• User interface design is hard: even communication between humans is hard, the UI is communication between machines and humans which is unimaginably hard.
• “The Superman Effect” : the best designed UIs make you feel like superman

What is it?

Ever wanted to capture the whole webpage you’re on? Not just the currently visible area? Awesomescreenshot does just that, and then some! It works with Google Chrome, Firefox and Safari and let’s you create full-page screenshots of a webpage. The awesome thing about it is that you can easily annotate the screenshot and share it. No need for Adobe Photoshop anymore, Snap the screenshot, add your 5ct and save it or share it online.

Why do I need it?

If you find yourself making a lot of webpage screenshots which you stitch together with Adobe Photoshop, this tool can save you a lot of work. It look slick, works fast and has the advantage of direct sharing: no more “save for web”->”open mail”->”drag to mail”->”wait for big e-mail to be sent”, sharing is only a matter of clicking: “upload to http://awesomescreenshot.com”.

Awesome screenshot in action

Could it be improved?

I’ve made some screenshot for this quick review and found that the annotation tools don’t always behave as you might expect them to. The blur tool doesn’t always work and the undo is flakey at best. But all-in-all I think these are minor annoyances that probably will be fixed by the author in one of the coming releases. I’ve tried the Safari version so these issues may not apply to other versions. Also after a quick test-drive on Firefox, the extension seems to have a more polished interface there.

Give it to me!

Awesome Screenshot is made by Diigo and you can get it at http://awesomescreenshot.com/

Version reviewed: 1.3.3 (Safari)

We use our mobile device while shopping, waiting in line, in the car, at home watching tv or – although some won’t admit to it – on the toilet. Still there are companies that insist on stripping everything off their website that has a slight chance of interesting me as a visitor only to provide me with a website on a weight watchers diet just because they think they know what I’m looking for. This always leaves me with a nasty aftertaste of what could have been a lovely experience.

But wouldn’t it be nice to somehow be able to add some context to our visitors? Well yes, of course it would! And I think that in the near future we will be able to do so. Just think of what your device can measure. We already have time and location, but what if our devices could analyse sounds and smells or measure our heartbeat. I agree that even with all that information we still wouldn’t know what our visitor is looking for so the option for an anorexic website is still off, but it would give us some idea of what our visitor is doing. And the more we know about our visitors, the more options we have for clever targeted content.

This might sound a bit far fetched, but I honestly think that it will not be long before our mobile devices don’t only know where we’ve been, but also know what we’ve been doing. And when they do, it’s up to us, web developers and IT professionals to tap into that information. But to do that, we need to start acting now. We need to start fattening up our mobile websites so that when the time comes we can offer the best experience to our visitors.

So here’s my plea for the for the future: let’s agree on leaving anorexic mobile websites in the past and focus on fuller and fatter user experiences in the future.

Things we want to cover:

• All things mobile (mostly web though)
• Cool stuff about HTML5 and other cutting-edge web techniques
• Social media related stuff
• Other webdevelopment topics