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.

• 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

• 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

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

• 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 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!

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.

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)

And as a bonus (if you haven’t heard about it yet):

Create your own, or better yet, be your own infographic with Timeline on Facebook.

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.

• The Mobile Workstyle

  How, when and where the mobile workforce works and how they keep up their productivity. Mobile and tablet use is rising quickly, especially for accessing e-mail.
  http://blog.gist.com/2011/08/09/the-mobile-workstyle-infographic

• Why Mobile Users Aren’t Checking In

  Why people would or would not consider checking in. Interesting is that this infographic also considers people that would consider checking in and people who talk about checking in. Related to this infographic: “Foursquare Useless (for now)” on infoarch
  http://mashable.com/2011/05/04/social-location-apps-study

• The History of Android

  A timeline of Android as a company, but mostly a timeline of the different Android versions with their cute cookie-names (Cupcake, Donut, Eclair, Froyo and Gingerbread).
  http://mashable.com/2011/07/26/android-history-infographic

• The Internet of Things

  In 2008, the number of devices that connected to the Internet exceeded the number of people. That number continues to rise, thanks to a growing number of connected devices and gizmos, ranging from televisions to soda machines. The folks at Cisco have put together this infographic to showcase the growth of the Internet of things.
  http://gigaom.com/2011/07/17/the-internet-of-things-infographic/

• Diagram of Geek Culture

  A geeky map about geeks with: types of geeks, geek obsessions, their social hangouts and their language including terms they use and are associated with.
  http://blog.juliannabrion.com/2009/12/geek-map.html

• Edward Tufte’s “Slopegraphs”

  Not really an infographic perse, but a description of an interesting and minimalist visualization technique to show increases and decreases over two points in time.
  http://charliepark.org/slopegraphs/

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