Mest lästa vecka 40

Här är listan på förra veckans mest lästa artiklar på svenska.yle.fi. Och påpekar att dokumenten inte är en omfattande analys om sajtens besökarstatistik utan innehåller enbart info om de mest lästa artiklarna på den nya plattformen.

https://docs.google.com/open?id=0B1gre8H-DNuHU0p5ZHJuZnVUNlU

Och ja, nästa version ska innehålla mera information och den ska finnas på svenska.yle.fi. Återkommer.

 

Theme layer i Drupal 8 – DrupalCon

Under Drupalcon i Munchen kunde man bekanta sig med de projekt som är på gång inför Drupal 8 (planerad lansering Augusti 2013). Det projekt som kommer att påverka flest användare är Spark / Dries tillkännagivande av Spark. Spark är en WYSIWYG editor som fungerar direkt på sidan, responsiv layout designer, mobil verktygsfält och mobil anpassningar. Allt detta gör det mycket lättare att se hur de ändringar man gör ser ut.

En demo hur Spark fungerar

Spark kommer att finnas som contrib för D7, och målet är att bli del av Core i D8.

Kärnan i Spark utgörs av Aloha Editor som Drupalcon till ära tillkännagav att de ändrat sin licenseringsmodell så att Aloha kan användas i Drupal utan restriktioner.

Aloha Editor är den mest imponerande WYSIWYG editor jag sett. Det är inte bara kodmässigt en bra lösning, utan den ger också användaren en mycket bättre användarupplevelse – mer i stil med hur man redigerar text i Word eller Google Docs. Den klarar till och med av att hantera text som kopieras från Word utan att markupen blir full av onödig kod.

En klar fördel med Spark är också att ”förhandsgranska”-funktionen blir onödig. Detta för att ändringarna man gjort ligger färdigt framme med rätt utseende. På samma sätt som i ett textbehandlingsprogram kan man fritt ändra, för att sedan spara då man själv är nöjd.

Vi funderar på att antingen ta i bruk Spark på Drupal 7 eller att testa Aloha Editorn ovanpå våra befintliga lösningar. Att sätta den på de existerande redigeringssidorna (ej inline i frontend) vore enbart i sig lockande då redigeringsupplevelsen blir så mycket bättre.

Ett annat mål är att snabba upp front end, då den just nu i många system, inte bara Drupal tar en oproportionerligt stor del av tiden. Se t.ex. ”The performance golden rule”.

På BoF (Birds of a feather) diskussionerna om Drupal 8 talades det mycket om Twig som den nya lösningen för templat-lagret. Det verkar som om det råder en konsensus om att det är den bästa vägen framåt. Det jag främst tycker verkar fint är att man kan hämta ut innehållet ur Arrayn på ett tydligare sätt. Många funktioner flyttar också ut från templaten.

Här kan du se presentationen och höra ljudet från A designer-friendly theme system in Drupal 8?

Om du vill testa Twig finns det ett sandbox projekt här. Nackdelar som det talades om är Twigs licens-modell som ännu inte är kompatibel med Drupals, och att Twig som system på ett sätt introducerar ett till lager i templatsystemet.

@JohnAlbin visade också sin kartläggning av theme layer i D7 jämfört med D8. Det är en viss skillnad i komplexitet 🙂 Uppdatering 11.9 – här kan du jämföra kartläggningen av D7 med den i D8.

Det talades också om möjligheten att skapa genriska hooks, vilka kunder återanvändas av contrib moduler. Skulle isåfall kunna betyda mindre templat-kod i modulerna. Blir intressant att se om det blir av.

Kan också notera att temandet väcker större intresse, t.ex. tog sittplatserna slut vid åtminstone två tillfällen.

Missa heller inte Drupal 8: What you need to know.

Övrigt
@emmajanedotnet höll en bra presentation av vad man bör tänka på då man väljer bastema. Det här skulle jag själv ha velat höra för ett och ett halvt år sedan. Frågan är ifall ngt kunnat göra jämförelsen då, rätt mycket har ju hunnit hända. Har du inte valt bastema ännu, kolla på denna.

Case: svenska.yle.fi as a mobile first responsive design

This is a blog version of the presentation I held at Drupal Camp Helsinki 2.6.2012

If you prefer, watch this recording of the presentation:

So why mobile first web app, and not an app or mobile specific site?

We knew we wanted to have a mobile first responsive design, so we talked to people about what their experiences where and became even more convinced that this is the way to go forward.

I recently read two good blogposts on the subject, one by Josh Clark

“First, a growing number of people are using mobile as the only way they access the Web. A pair of studies late last year from Pew and from On Device Research showed that over 25% of people in the US who browse the Web on smartphones almost never use any other platform.” … ”There’s a digital-divide issue here. People who can afford only one screen or internet connection are choosing the phone. If you want to reach them at all, you have to reach them on mobile. We can’t settle for serving such a huge audience a stripped-down experience or force them to swim through a desktop layout in a small screen.” – Josh Clark

in Netmagazine and an other on by Bruce Lawson in Smashing magazine.

It pretty much summarizes they way we at svenska.yle.fi look at it.

By designing the system (not site, I see it much more as an ecosystem when designing responsive sites) mobile first, and not hiding content from mobile users you are reaching a bigger audience. The same by not requiring users to download an app and keep updating an app. It is also less expensive to maintain, and one has to remember the cost of marketing the app so that users find it.

With an web app/mobile first site shared content is always displayed in the best way possible for the end user, depending on the device.

The perhaps most successful web app is Financial Times. It is much more device tailored than our site, but we embraces the same thinking.

When we look at our numbers, we have gone up from 8.5 % mobile usage (of total traffic) in January 2012 to 13 % in May. – svenska.yle.fi

Actually making it mobile first

Making the site mobile first sets some limitations, and also affects the design process. People are designing from mobile to desktop, or from desktop to mobile. In my experience it works best to work on all sizes at the same time, while keeping the technical limitations of mobile in mind (designing in the browser, read more in this slide by Edward O’Riordan @edwardoriordan (Front End United 2012 Amsterdam).

Drupal, Omega and mobile first

The way Omega/Drupal includes (compresses) the CSS files prevents us from using javascript to load the CSS files only when needed (blogpost about how it could be solved).

The reason for wanting to use Javascript is because media queries always are loaded even though they are not used.

I am planning to try out if changing the weights of the CSS groups can join some of the compressed CSS groups we currently have.

We also ran into extra work with IE specific CSS files, as it is impossible to use weights to add them after the Omega CSS files. We ended up using more targeted CSS selectors for IE.

The amount of DIV’s is also something that is not optimal, as you can see in this image. More than half of the DIV’s could be removed.

Which theme, fluid or set of sizes?

The hottest theme in 2011 was Omega, and we decided to go with that one as we saw it as opportunity to get something off the shelf that was not perfect, but works. We wanted to focus our resources on making the solutions that were not available to us the best possible (and theme independent).

We decided to go with a set of sizes because it gives us better control over the layout.

I was asked a question during the presentation; ”What theme would you use if you would start from scratch with the knowledge you now have”. The answer is I don’t know, I would definitely look at what options are available – and most likely end up with a custom theme because of our specific needs.

Layout

We decided to go for a very sparsely decorated layout, to keep the UI clean and to make the basic responsive design as light as possible. We wanted to gain experience before we had built a swamp that it is difficult to dig yourself out of.

I also wanted to develop a new method, and embrace the possibilites – while leaving pixel perfect behind.

To do this I defined areas for graphics (at this stage the top of the page can be modified and display anything you like to make in Photoshop). This way I kept the layout completely CSS generated. An other defined area is for banners. They can be added anywhere, but we are still in the process of working out how they best are constructed.

Images

The first thing we tackled were images. Fortunately we have our own homebrew Image Management System (IMS) that made it possible to get the images in many different sizes.

The solution we implemented first displays a regular small image that works on mobile, and then if javascript detects that the screen size is wide enough switches to a bigger size.

First load

<img itemprop="image" alt="VPS, augusti 2011" title="VPS slog HJK." src="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_6.jpg" width="200" height="113" class="imsImg" data-ims-id="58628" />

After the javascript has been loaded

<img itemprop="image" alt="VPS, augusti 2011" title="VPS slog HJK." src="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_5.jpg" width="200" height="113" class="imsImg processed" data-ims-id="58628" data-src-fluid="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_5.jpg" data-src-narrow="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_4.jpg" data-src-normal="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_6.jpg" data-src-wide="http://static.yle.fi/ims/imssv/2011/36/586284e6cf0a1e58bb/586284e6cf0a1e58bb_5.jpg">

In the javascript we have set different sizes to be loaded depending on the image size that best fits the layout template the image is displayed in. The layout template also has different settings per size.

To prevent the images from making the page flicker when the bigger image is loaded and inserted into the page we specified the image size in the CSS. This makes the image look blurry for a while when the page is loading, and then has a “sharpen” effect when the bigger image is displayed.

Video & audio

Most of our videos and audio are embedded from our media service Arena, and fortunately it was also being rebuilt at the same time. This meant that we got a Flash free first embed, that has a big effect on our mobile first approach and the rwd solution is out of the box. The solution could be improved by making the embed mobile first (the image is one size only). Flash is required for playback.

For Youtube and Vimeo we are using FitVids.js

KB size and http requests

The image and video solution means that the KB size was solved. One can argue that only one image file should be sent to the desktop users (instead of two), but I find the solution benefiting also them, because the image will display faster even though it is blurry.

To limit the amount of http requests, KB size and user experience (quick load for all sizes) we made the social media share buttons load only after the user on desktop hover on the text. On mobile they are loaded only after the user clicks on them.

To make articles load quickly only the article itself and content closely associated with the article is loaded (article text, image, lists of related articles, most read, most commented). If the javascript detects that there is sufficient screen space it loads the content of the subject page the article belongs to. If not, links are displayed that takes the mobile user to the same content.

So did it pay off? I think so 🙂

The data was collected with Yslow for Firefox.

The reason the subject pages are not lighter on mobile is that we currently do not have a breakpoint that would allow us to not load part of the page content on mobile (but offer a link like we do on articles).

Lessons learned

In Views, always unclick to remove the extra markup – and give the block a unique style name so that your CSS is not dependent on block names.

We used a small image in our first iteration, and got feedback on that it was to small – so we changed that. Now we get some feedback that it is too big. I think think this is related to the fact that mobile is becoming the primary device, and you want to have the full version – you don’t want a preview that forces you to use a desktop to see the full image. So some more work needed to make all user types happy.

Iframes and auto height is causing grief. No perfect solution yet.

What to do next

  • Improve the theme / switch to a newer one
  • Improve on Twitter, Facebook integrations – they are not working correctly with the responsive design
  • Other external resources such as data visualizations, weather, sport results
    Responsive visualisation with Raphael
    Small enough to work on mobile
    Sports results – not responsive at all
  • Work more with the layout
  • Implement bigger images on desktop (that is why we currently have a grey box next to images in articles – backend is not done yet)
  • Build a content breakpoint on subject pages

This is the presentation itself (via Slideshare)

Yle byter visuellt utseende

Det har varit endel jobb med den gamla plattformen den sista tiden. Vi har förberett den för bytet till Yles nya visuella utseende.

Det är en utmaning att hitta alla ställen de gamla logotyperna existerar! (Tipsa mig om du ännu ser någon 😉

Det kan löna sig att tömma webbläsarens cache för att du säkert skall se ändringarna på svenska.yle.fi & co – det beror på att dels är våra egna cache (tillfälligt minne) servrar effektiva, men även webbläsarens cache kan ställa till det.

I och med att vi snart migrerar till S.Y.N.D handlar det främst om att sidans huvud och fot fått ett nytt utseende på våra gamla sajter. Du känner bra igen att största delen av den gamla sajten finns kvar med samma visuella utseende som tidigare.

För S.Y.N.D:s del går det också framåt, och inom några veckor skall vi börja köra sajten live internt. Efter det blir det en publik beta där alla intresserade kan bekanta sig med hur vi inom S.Y.N.D använt oss av Yles nya visuella utseende.

Här kan du se hur sajten just nu ser ut (skärmdumpar från vår utvecklingsmiljö, så texterna är inte representativa och vissa texter är ännu på engelska.)

Fast en del arbete kvarstår ser ni här en version som är rätt nära lanseringsversionen – det blir en ren layout som lyfter fram innehållet samtidigt som den tar hänsyn till den typ av apparat man använder.

Om du vill få en inblick i vad den responsiva designen kan betyda i praktiken kan du gå in på svenska.yle.fi/programguide med en apparat som har en skärmbredd som är mindre än 480px (fungerar också att bara krympa webbläsarens fönsterstorlek). Rent tekniskt är det en begränsad responsiv design lösning eftersom den tekniska plattformen inte ändrats.

Trimming the fat: reducing http requests to keep us on the mobile first diet

In an attempt to follow the ‘mobile first’ ethos, reducing the amount of loaded assets on smaller devices is high on the priority list.

Using media queries we can effectively control the loading of things like background images, but what about the CSS itself? After all, it seems wasteful to load CSS specifically for desktops when viewing a site on a mobile device.

A common misconception of media queries is that a device only downloads the CSS of a matched query (when using the query in the media attribute of a link element).

This is not the case.

All CSS files are downloaded regardless, though the CSS is not applied until you match the requirements of said query.

I feel like I’m being slightly cheated. In an ideal world I’d like the CSS to only be downloaded when they are needed, based upon matching the requirement of the media query. So how can I watch my http requests and keep my slimming mobile figure?

JavaScript to the rescue, or JavaScript polyfill time.

We could easily use a bit of JavaScript to achieve this, the fine fellows over at the BBC use the following on their blog:

<script type="text/javascript">/*<![CDATA[*/
 (function(){
  var importStatement = "";
  switch (true){
   case ($dc.screenWidth > 639):
    importStatement = '@import url("http://some.tablet.css") screen and (min-width: 640px);' + importStatement;
   default:
   importStatement = '@import url("http://some.compact.css") screen and (max-width: 639px);' + importStatement;
   break;
 }
 document.write('<style type="text/css">'+importStatement+'</style>');
 })();
/*]]>*/</script>

If you are willing to travel the JavaScript route then something like this works fine. However, when you add a content management system on top of this it gets more complicated.

Dealing with Drupal

Our previous example was very basic, aren’t all examples?! When we consider taking this approach in Drupal we come across a few hurdles.

Drupal’s CSS optimisation aggregates and compress theme, core and contrib CSS together into a greatly reduced number of files. This is great, not least because there seems to be a huge amount of core and contrib CSS in Drupal.

But as soon as we do this we loose the ability to control our CSS for different devices with a little more finesse.

A module in the making?

Ideally there would be a module which would do the following:

  • Show a list of all CSS which is put out by the system, theme, core and contrib, preferably with a description as to its purpose.

Do you know where/what all of the CSS Drupal spits out is? Probably not. I’ve never sat down and gone through all of these files and figured out exactly what they do, and indeed if I really want them. On more than one occasion I’ve found myself writing CSS to override stuff from them. This shouldn’t be the case.

  • Allow selection/deselection of said CSS, removing what you don’t want.

An ability I’ve always longed for, yet it’s never been that important to warrant the time to actually figure out how to do properly (it’s generally been quicker to just override it in the theme). But, this is the ultimate, complete control on what styles are used.

Traditionally you’d simply override an unwanted style sheet in the theme info file by using an empty declaration with the same name. In some themes, most notably Omega, this feature is now offered as a theme setting. It allows you to switch off core and theme CSS.

  • Specify groups which are separately optimised.

Having Drupal optimise our CSS is a good thing, but as stated, it kind of walks all over our plans to deliver style sheets as needed rather than the whole lot together. Having the ability to set specific groups would be great. I could then lump all core/contrib stuff together and then have the needed separate—compressed—files for my ultimate goal!

I hereby name this module CSS Admin.

Pragmatically thinking

We’ve specified a useful CSS administration module there, and so in a modular mind set the features left to finish our solution should probably be rolled into another module which is just dependant on CSS Admin.

We need the ability to:

  • Write some JavaScript into the head of the document that tests the screen width (or other variables) and then loads an appropriate CSS file.

Perhaps we could call this CSS Admin – Media Query Loader.

That’s it. Simple!

Glory awaits

Perhaps deferring the loading of CSS files is getting too picky, but I’d don’t think so. Granted, I’m probably missing a few angles of reasoning from this, but I think the core message is sound—we should be doing everything to honour the mobile first ethos by asking these kinds of questions and seeking out their solutions.

I’ve no doubt creating those modules is possible, I’ve worked with some excellent Drupal developers and I’m sure there are plenty more out there. With any luck we might get to look at this during this project and I’ll be able to follow up with a solution post, but for now I’ll make do with seeding the thought amongst you all.

Knowing my luck, in true Drupal fashion, a module already exists for that! I hope it does, but I’ve yet to come across it.