Feed aggregator

New to Mobile Learning Development: 3 Big Problems and 7 Solutions

Mobile learning from MLearnopedia - Fri, 04/17/2015 - 20:01
New to Mobile Learning Development: 3 Big Prob- lems and 7 Solutions Mobile Learning is Here to Stay With the introduction of the Apple iPhone and iPad, a mobile computing revolution. began. With competition from Google, Blackberry (RIM), Microsoft, and HP heating up. from all sides, smart phones and tablets are here to stay. devices? issues. Rapid.

Brought to you by: Mobile Learning
Categories: Mobile learning

Creating a Successful Customer Journey with Text Messaging

Mobile learning from MLearnopedia - Fri, 04/17/2015 - 19:06
'A new report by Salesforce highlights the direction that marketers are headed – and where they should go if they’re not there already – for a successful 2015. The report points out that mobile is “the most important and crucial technology” for marketers to focus on in order for customers to have a successful customer journey.

Brought to you by: Mobile Learning
Categories: Mobile learning

Accepting Our Lack of Control

A List Apart - Fri, 04/17/2015 - 12:30

It’s easy to forget that our users have ultimate control over how they view the web, even though it has been said before. As people making the web, we merely offer suggestions. These suggestions of ours should make it easier, not harder for people to access our content in the manner that best suits them.

Over the course of the last year I’ve worked on several projects for a wide array of products and sites. The common denominator across all of them was an end goal of a responsive site. Often that’s where the commonality ended, though. In some situations not everyone agreed or accepted that we lack control when it comes to how users experience our sites.

As I work and write CSS, I try to do so in a way that acknowledges that I don’t have ultimate control. For instance, I prefer to use rems with a pixel fallback, ensuring that my line heights are unitless and work with whatever unit the font is in. That has the added bonus of not having a negative effect on the children of the element. In addition, I often prefer to base my breakpoints on the content of a page, rather than a set of device sizes. That can make the code a bit harder to maintain, but it benefits users. When it comes to grids, I’m happy to use percentages and let the browser round for widths and gutters to make things work.

Of course all of those things mean we are giving up some control. When your line height isn’t an exact pixel number, you’re letting the browser decide and do some math. It may not look perfect. When you allow content to drive breakpoints rather than using standard breakpoints, you may have more complicated CSS to maintain. And with grids, as with line heights, when you allow the browser to do some of that work, the rounding may not always end up the way you desire.

I’ve come to a place of peace with this lack of control, and at times I even enjoy it. The reality is, users ultimately have a lot of control: they can change their base font sizes, they can zoom in, they may even be reading our content in a different application, such as an RSS reader. The user gets to decide how they want to view and use our sites and applications.

Not everyone I work with is as excited about losing some of the perfection, though. Many would prefer to be more precise with the CSS so that it looks exact in their browser of choice. But doing that would mean not allowing users to have as much control over the experience, and could mean a poor experience for some.

When confronted with concerns or objections from teammates who would rather have more perfect CSS, I do my best to outline the reasons behind these practices. We need to be user-friendly, future friendly, and accept the “ebb and flow of the web,” so that the things we build can be viewed on whatever device comes along. As Anna Debenham reminds us, many users are grabbing what’s convenient, not necessarily what will give them the perfect experience.

Learning to be ok with the ebb and flow of things allows us to think differently about how we can work with and use the web. As Frank Chimero writes in his wonderful essay “The Web’s Grain”:

So, those media queries we write? It might be time to stop calling them breakpoints, and instead consider them points of reassembly.

As I think about how I advocate for allowing the web to be the web, I’m drawn to Frank’s idea. Instead of making our sketches fit on the web, I’m trying to make our ideas and content work inside the various edges of the web as it appears across a myriad of devices.

Which brings us right back to what John Allsopp said so well fifteen years ago:

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.”

This tension of how we build for the web probably isn’t going away any time soon, but as Paul Ford reminded us last week: neither is the web—it will survive and continue on.

Categories: Mobile learning

Proposal for a Round Table at ECER 2015 in Budapest accepted

London Mobile Learning - Thu, 04/16/2015 - 14:36
Our proposal for a Round Table at the ECER 2015 conference in Budapest was accepted for Network 6 'Open Learning: Media, Environments and Cultures'.


Colleagues involved

    Judith Seipold (convenor), London Mobile Learning Group (LMLG), CH
    Norbert Pachler, UCL Institute of Education, University College London, UK
    Klaus Rummler, Zurich University of Teacher Education (PH Zürich), CH
    Ben Bachmair, formerly Universität Kassel, DE
    Maria Ranieri, Università degli Studi di Firenze, IT
    Keith Turvey, University of Brighton, UK


Title

Mobile Learning: Learning Across Contexts - Learning In Transition.


Abstract

Mobile learning as a global phenomenon is considered to offer new opportunities for teaching and learning as mobile technologies can be used inter alia to realise personalised and learner centred approaches (see e.g. Sharples, Corlett, and Westmancott, 2001), to find ways to include learners who are at a distance to formal education (see e.g. Pachler, Bachmair, and Cook, 2010), to realise collaborative and networked learning formats (see e.g. Traxler, 2010), to address topics that are related to ethical dimensions in educational contexts (see e.g. Wishart, 2011) etc. This is why some advocates of mobile learning argue it is (a pathfinder for) ‘new’ and ‘future’ learning. However, the question arises why this shift in the belief that learning changes significantly through the use of mobile technologies? What is actually behind populist assumptions such as ‘new’ and ‘future’ learning? In what way does or is learning changing - and what can research, theory, practice and politics contribute and learn from this change?
The round table will adopt a dialogic approach with presenters engaging participants in a critical discussion around topics such as ‘innovation’ and, related to it, the ‘transformation’ of learning that is inherent in the affordances and use of mobile technologies in educational contexts. The round table will discuss mobile learning as agentive and meaningful activity and cultural practice rather than adopt a techno-centric perspective. Impulses for innovation and transformation in learning through mobile learning will be explored as well as differences and commonalities across different European countries; there will also be a consideration of structural limits confronting mobile learning.
The round table will frame learners as drivers of innovation and transformation of learning, and their agency and their cultural practices will be in the foreground. It will also give attention: to structures that are relevant for learners in their learning, appropriation and meaning-making processes; to the educational system that has to react to mobile learning practice in order to ensure sustainability; and to learning theory, practice and methodological implications.
Specific reference will be made to: to participatory narrative methodology (Turvey, 2014); ‘problem spaces’ (Turvey & Pachler, forthcoming); learner generated contexts (Seipold, 2014); contextual learning (Bachmair & Pachler, 2015); social justice as institutional prerequisites within life accomplishment and together with the recognition of difference (Bachmair, forthcoming); mobile storytelling (Ranieri, 2015); consequences for learning and policy development (Seipold, 2012); and to implications for teacher education and teachers’ perspective on mobile learning (Maurer & Rummler, 2014; Turvey, 2014).
Relevant framing questions for discussion at the round table are:

Agency and structures
    What is the role of learner activity in transformation?
    What is the relationship between learner agency and structures?

Places and contexts
    Under which conditions is this merging of contexts fruitful for learning? When is it disruptive?

Benefits and limits
    What are the benefits of mobile technologies and their affordances for learners, teachers, and the education system?

Role of teachers and learners
    What are the consequences for the roles of learners and teachers?

Policy, educational system and teacher education
    What does learner centring mean for institutional learning?
    What is the impact of the introduction of mobile technologies on educational structures?
    What systemic action is needed to ensure sustainable structures and approaches?
    What are the implications for teacher education?

Research and interdisciplinarity
    What are the relative contributions of different scientific disciplines?


Date, time and place

Will be available by the beginning of July.
Categories: Mobile learning

Coming May 6: Sass Talk

A List Apart - Wed, 04/15/2015 - 15:23

To preprocess or not to preprocess? Every time we run a piece about Sass (which we’ve done a lot of lately), we get tons of thoughtful comments on both sides of the issue. Here are just a few:

There is no ‘dark side’ to pre-processors… Writing CSS Vanilla on a website with a large scale is just asking to be a maintenance nightmare in my eyes. Iain Spad I like writing vanilla CSS. It lets me have an intimate relationship with the code and it means I know everything that’s happening and why. garek007 It’s not just garbage in, garbage out. It’s garbage in, 10x garbage out. But, used wisely, such tools are very valuable. Matthew Gifford

Our next ALA: On Air event will continue these conversations. Join us on May 6 as our panel cuts through the clutter and shares how they’ve chosen to incorporate (or not) preprocessors and task runners in their work.

Event details

This event is free and everyone is welcome—but you have to register to participate in the Q&A. Here are all the details:

Wednesday, May 6
1–2 p.m. EDT
via Google Hangout
Register or get more details

We’ll have 30 minutes of conversation between our panelists, and then open things up to questions from attendees. Like we did with our last event, “Designing for Performance,” we’ll also share the full video and transcript after the live show ends.

Join our email list to get updates when new events, videos, and transcripts are posted.

The panelists

We’ve rounded up a few brilliant ALA contributors to participate:

Big thanks to Pantheon

Putting on events is a ton of work, and we couldn’t do it without the generous support of our sponsor Pantheon. Sign up for a demo to see Pantheon’s unified platform for building, launching, and running Drupal and WordPress sites.

Categories: Mobile learning

This week's sponsor: Web Designer News

A List Apart - Wed, 04/15/2015 - 14:15

Thanks to Web Designer News for sponsoring A List Apart this week! Take a look at their curated stories for designers and developers.

Categories: Mobile learning

How to Sound like an SMS Pro

Mobile learning from MLearnopedia - Mon, 04/13/2015 - 20:06
'Nearly everyone sends and receives personal text messages on a daily basis. But a text messaging campaign is a much more sophisticated use of text messaging technology and involves a lot more than just typing a message and hitting “send.”. Step 1: Know the lingo. The first step to sounding like an SMS pro is learning the lingo. That’s right!

Brought to you by: Mobile Learning
Categories: Mobile learning

3 Augmented Reality Smart Glasses You Should Know About

Mobile learning from MLearnopedia - Mon, 04/13/2015 - 17:38
'Smart glasses can be used to improve employee performance. In this first of three posts, we review the hardware with which we''ve been experimenting. Mobile Apps Mobile Devices Research Android augmented reality Epson Moverio Google Glass ODG R-6 smart glasses wearables

Brought to you by: Mobile Learning
Categories: Mobile learning

Lyza Danger Gardner on Building the Web Everywhere: WAI-finding with ARIA Landmark Roles

A List Apart - Thu, 04/09/2015 - 12:28

Recently, as part of my research for a presentation about web accessibility for non-specialized teams, I asked around about how people were applying the HTML role attribute in their day-to-day web practice.

Their answers didn’t surprise me. Many expressed chagrin at their apparent ignorance, admitting they copied and pasted examples a lot. Some had a passing familiarity with a few prevalent roles, but sensed beyond that a gaping chasm of things they didn’t know. The prevailing tone was guilt. It’s not that people don’t care about accessibility, it’s that the topic can feel overwhelming among all the other priorities we have.

I’ve noticed a lack of easily-Googled, applied documentation for certain technologies or practices. On one end, we have specs, sometimes exhaustive. On the other end, we have a smattering of implemented examples. Synthesized documentation can be thin on the ground.

I can’t change the world, but I can add some analytical documentation about something specific: my nutshell-in-a-nutshell view of landmark roles in WAI-ARIA, as I understand them, and as it translates to more easily adding website accessibility to your daily workflow.

The Accessible Rich Internet Applications (ARIA) suite from the W3C’s Web Accessibility Initiative (WAI) is one piece of the web accessibility puzzle. Now, the first rule of ARIA usage is—I am not making this up—we do not use ARIA (unless we need to). Before you set out to use it, you should already have a solid authoring craft: careful, semantic treatment of content; proper use of attributes and textual alternates; sensitivity to contrast and font sizes. Support for accessibility leads to well-crafted HTML and vice versa.

How ARIA fits in

Applied ARIA in HTML is a combination of two things: roles and aria-prefixed attributes. Roles identify an element’s purpose, and attributes describe things about it (properties) and what it’s up to (states).

ARIA is a gap-filler for HTML semantics. It allows you to be declarative beyond what HTML elements and attributes currently provide, and lets you be explicit about the relationships and meanings of elements on your page. It also provides a mechanism to attach semantic meaning when authors, by perversity or necessity, use non-standard elements to represent other things (e.g. using a div as button).

The ARIA specification provides a standardized way for browsers and assistive technologies to evaluate HTML documents for people who access and use the web in different ways. There’s a lot to know about ARIA, and we don’t have all day, so today I’m going to focus on one important topic: landmark roles.

Landmark roles for daily use

The HTML element attribute role is the piece of the ARIA iceberg most often visible above the waterline, and the chunk of ARIA most immediately recognizable to web builders. <div role=“main”> (or even <main role=“main”>) may be familiar to some of us.

main is one of a set of eight defined ARIA landmark roles. All defined roles express an element’s purpose, but landmark roles serve as key milestones, allowing AT (assistive technology) to map the lay of the land of an HTML document. This is why they’re a great set of roles to start with. Landmark roles make navigation between areas of your page more efficient for different kinds of users. They help convey basic semantic intent and can serve as hooks and helpers for other technologies (or even humans reading your source).

Here are some landmark roles that can be used on practically every HTML page you write:

  • main: The main content of a document.
  • banner: The main header or masthead of a page; typically assigned to a header element.
  • navigation: A collection of links for navigation. A common usage is <nav role=“navigation”>.
  • contentinfo: A collection of metadata, copyright information and the like. Commonly applied as <footer role=“contentinfo”>.
Those other landmark roles

There are two further straightforward landmark roles you might be interested in: complementary—a chunk of content that supports main but remains autonomous, and search—an element containing your site’s search interface.

The application landmark role should be used with care, so read up first if you want to use it. form is also a landmark role, but arguably redundant if you use it on a form element (doesn’t <form role=“form”> seem repetitive?).

When are roles redundant?

Here’s where it gets foggy. I’m arguing that <form role=“form”> is redundant and yet suggesting <main role=“main”> (or maybe <div role=“main”>) is good practice. What gives?

Roles are semantic extenders. One of the things they do is provide training wheels for semantic elements that don’t exist or haven’t been adopted fully by all browsers.

It’s safe to anticipate that all major browsers know what a form element is—its role is implicit in the element itself. This is less reliable, however, with the main element. Presently, Chrome and Firefox require <role=“main”> on an element to make the semantic role available to assistive technology and IE is all, main? Never heard of it. So we role on until broad adoption.

Though I lean slightly toward not using <form role=“form”>, there are varying and vigorous views on this (and other aspects of ARIA). Don’t take my opinion as fact.

Where to next?

I talked about documentation being thin on the ground. That’s not untrue, but it gives short shrift to some fabulous efforts. There are some killer resources, like a11yproject.com’s accessibility checklist. That’s exactly the kind of applied reference web generalists need. Analytical documentation targeted at web implementors isn’t completely absent, although there seems to be a scarcity of it compared to other topics.

There is far more to ARIA and accessibility. While landmark roles are a great place to start, your growing understanding may lead you to other kinds of roles (there are four categories, of which landmark is one) and to aria-*prefixed state and property attributes.

What I’ve talked about here only begins to scratch the surface. But even if all you do is commit to using some of the ARIA landmark roles in your HTML, I am a happy person.

Categories: Mobile learning

Add Pictures and Animated GIFs to Your Text Message Campaigns

Mobile learning from MLearnopedia - Wed, 04/08/2015 - 16:55
'Mobile Commons is excited to announce that all of our shared shortcodes now support Multimedia Message Service (MMS). This means that you can send and receive pictures and animated GIFs as part of your text messaging campaigns! With MMS, you can upload media files and include them in your conversations just like regular text messages.

Brought to you by: Mobile Learning
Categories: Mobile learning

Research instruments investigating Self-Directed Learning in #MOOCs #SDL

Mobile learning from MLearnopedia - Wed, 04/08/2015 - 10:36
'In reply of a question asked by the inspiring colleague and rising academic Bernard Nkuyubwatsi from the university of Leicester, I have grabbed my three research instruments and put them on Academia, here. thought it would be good to share this already. writing updated chapters, but will take some time.

Brought to you by: Mobile Learning
Categories: Mobile learning

Research instruments investigating Self-Directed Learning in #MOOCs #SDL

Mlearnopedia - Wed, 04/08/2015 - 10:36
'In reply of a question asked by the inspiring colleague and rising academic Bernard Nkuyubwatsi from the university of Leicester, I have grabbed my three research instruments and put them on Academia, here. They are part of a research rationale which is partially shared in my probation report which you can find here.

Brought to you by: Mobile Learning
Categories: Mobile learning

15 Years of Dao

A List Apart - Tue, 04/07/2015 - 14:30

John Allsopp’s prescient essay is about the tension between the culture of print design and the culture of web design, circa 2000. That tension persists—not just between print and web, but between people who see the web as a publication medium and those who see it as a software development medium. It persists between people who see the web as a media delivery platform and those who see it as a software experience framework. We are still fighting the same fights—not just over text, but also over video, audio, interactive content, CSS minimizers, grid systems, and JavaScript frameworks. The HTML5 standard is nearly as long as Infinite Jest, so there’s a lot to discuss.

The last 15 years have taught me that dynamism is in the eye of the beholder. My sensible publishing pipelines might look like digital chaos to a traditional print publishing person; their well-organized process looks fragile and balky to me. What I’ve come to understand is that all of us who work as craftspeople in digital media, whatever media or technology legacy informs our work, are seeking the same thing: order. Our audiences may want novelty, argument, gossip, and frolic, but we need order in order to deliver these. Standards bodies, licensing organizations, CMSes, character encodings, commercial software, venture-backed startups, shared spreadsheets—those are the tools we are using, as a culture, to prototype new cultural patterns along more orderly lines.

I don’t know if the issues raised in “A Dao of Web Design” can ever be resolved, which is why the article seems so prescient. After all, the Tao Te Ching is 2500 years old and we’re still working out what it all means. What I do believe is that the web will remain the fastest path to experimenting with culture for people of any stripe. It will still be here, alive and kicking and deployed across billions of computing machines, in 2030, and people will still be using it to do weird, wholly unexpected things.

Paul Ford, Writer


I first read John’s “Dao” essay when I chanced upon ALA while researching web development to set up the long-gone “glasshaus” book publisher. I’d read lots of boring stuff about ASP, PHP, ColdFusion, and lots of stuff about “creating killer websites,” but nothing that helped me understand what the main defining aspect of web development was. And this was it. John’s ideas of flexibility being a feature led me to become interested in accessibility—our inaugural flagship book was the first book on web accessibility, and it launched my career.

I read “Dao” again regularly and love pointing the new generation of web designers to it—the siren song of pixel-perfect designs that only look great on an iThing still seduces and deludes today.

Hence, the essay is still important now; it hasn’t aged at all. Just like its author.

Bruce Lawson, Open standards advocate at Opera


As American philosopher Dominic Toretto once famously said, “The thing about street fights…the street always wins.” For years we waged a fight for control over the web. We tried imposing our will upon it. We tried taming it. We complained that it wasn’t bending to our will. We were idiots. John Allsopp understood this before many of us. The street always wins.

Mike Monteiro, Design director at Mule


Markup is music. A Beethoven piece or a Metallica song will be the same—and not be the same—when played by an electric foursome or a full orchestra. Amazingly, “Dao” is more relevant 15 years later with the rise of mobile and true multiplatform content consumption.

Brian Alvey, CEO of Recurrency


As designers, we often focus on the rituals of designing for what is.

Devices that have been introduced since this article, like smartphones, tablets, and the Apple Watch, arise and we immediately seek to force our existing realm into it. To design “for” it with precision and refinement. Make the web work here!

While this approach is a necessary step, these devices are a bridge between what is and a future not yet realized. Devices like these gently nudge us into new behaviors, new ways of thinking and doing. John is exactly correct when he writes about letting go of control to become flexible.

Jaimee Newberry, Advisor, trainer, coach, speaker, writer


I often revisit John’s article when I need a reality check about what the heck we’re all creating here. Or after I’ve been sobbing, gently, because of browser inconsistencies. The more people read it—and really understand it—the better the web will be.

Dan Cederholm, Cofounder and designer of Dribbble, founder of SimpleBits


I wonder if I ever would have read John’s brilliant article had he titled it, “Click here to find out 10 things you thought you knew about the web that will still be completely true in 15 years! You’ll never guess what happens next!” I’m not sure. However, I am sure the “Dao” was a great read then and it’s a great read now, even if it isn’t top clickbait in 2015.

Jenn Lukas, Front-end consultant


Standing the test of time in a world defined by a dichotomous amalgam of ephemerality and persistence, a platform driven by an unrelenting pace for evolution, John gave us the intellectual building blocks for a generation to grow up with access to the web as a given, and a framework by which to do right by the web itself, no matter what imaginative new idea we create for it.  “A Dao of Web Design” continues to inspire and be relevant.

Faruk Ateş, Creator of Modernizr


I had never read this. I had never seen this. I think this must have been published just before I started to look at the web seriously. (From 1996 I had been looking at it quite playfully, with reverence, but never with seriousness.)

But, like I said: I had never read this. And I opened it now expecting just to peek. You know, glance and then close the tab. I read it all. It’s a wonderful article. It’s incredible to think about how myopic our universe was back then (as always is the case), how disjointed all the rendering technologies were, and how the biggest device discrepancy was a Windows display at 96 dpi or a Mac at 72 dpi. And yet everything holds true—even more so in an age where there is no way to anticipate screen size, dpi, or context. The magic of the web today is that it’s accessed by every kind of device—now ranging in the tens of thousands of variants at the least, scaled up from a mere two. The only way to build for such a thing is to be adaptable. And here is Godfather John, 15 years ago, telling us precisely how to build and think for the chaos and grandeur of the web for which we build today. Thanks, John, for putting this clear and critical stake in the ground so very long ago.

Craig Mod, Writer and designer


The future was already all there, written down in front of us—we just couldn’t see it yet. John knew, though. Accessibility, relational font sizing, “adaptive” design—and this was 15 years ago!

Daniel Bogan, Senior software engineer at Zendesk


For me there’s more to “Dao” than flexibility. This passage sticks out:

Think about what your pages do, not what they look like. Let your design flow from the services which they will provide to your users, rather than from some overarching idea of what you want pages to look like. Let form follow function, rather than trying to take a particular design and make it “work.”

Over the 15 years since John’s article, we’ve seen the call for function over form, content over creativity, taken to an extreme, where much of today’s web design lacks the spark of an idea that makes what we do memorable. Ideas still matter, and the look of websites matters, too, to communicate ideas about a product or a service or a brand.

Making a website “pretty,” understanding layout, seeing typography—really seeing it—and creating color palettes that evoke emotions are skills that designers should be proud of.

If John were writing “A Dao of Web Design” today, I’d ask my friend to remind his readers that the web is a medium for communication outside of “function.” That it’s a place for creative experimentation as well as for “services.” That it’s all these things and more.

Andrew Clarke, Art director and designer at Stuff and Nonsense


I went to school to learn how to control everything about design: typography, color, layout, distribution, medium, and context. Design concepts are difficult to understand without building a mastery of the tools and medium. John Allsopp’s article suggests that web design is a paradox: in order to have control of the web, you need to let go of trying to control it.

What makes this piece enduring is that it is not just about practically designing for the web, but also about being a web designer. Flexibility, adaptability, and accessibility are not just the attributes of good websites; they’re also what makes a good designer and teammate.

Samantha Warren, Independent designer


Like everyone else, I started my HTML markup days trying to wrestle with how to make it do my bidding. Reading over John’s essay now, I shudder to remember the pixels versus points versus font sizes debate, or the thicket of issues related to color cross-platform and early stylesheet implementations, and the whole <em> versus <i> question, but the core message still shines. Flexibility is key, and not just with respect to one design, but the possibility that a well-structured markup document can have potentially infinite actual expressions, each the result of an interaction between user preferences, browser capabilities, and gentle suggestions on the part of a designer willing to embrace a myriad of possibilities while appreciating that constraints drive creativity. Web designers don’t do one design, they do thousands, even within the same page or template. That “Dao” predates CSS Zen Garden or progressive enhancement or responsive design by several years is a testament to Allsopp’s deep understanding of what for me is the core characteristic of web design. That he wrote it so soon after the browser wars and before widespread and reliable CSS implementations is a marvel.

Steve Champeon, Lead researcher for Enemieslist


We once took the tropes of print design and tried to apply them to the web. I fear that today we run the risk of treating web development no differently than other kinds of software development, ignoring the strengths of the web that John highlighted for us. Flexibility, ubiquity, and uncertainty: don’t fight them as bugs; embrace them as features.

Jeremy Keith, Shepherd of unknown futures at Clearleft


When “A Dao of Web Design” was published, I was a computer science student and I didn’t build websites. But this article must have settled in the back of my mind, because when I started creating websites, I did my best to make them fluid and accessible.

Afterward, every time I had to use fixed widths for some reason, I felt like I was cheating on the web—like I was doing something wrong.

Every time I teach web design to a new class, I cite this article to my students (who are graphic designers) to highlight the differences between designing for the web and for print.

Valeria Brigatti, Founder and creative director of Italian A List Apart


John’s piece came three years before Steve Champeon coined the term “progressive enhancement,” but it clearly and succinctly outlined its philosophy: “Make pages which are accessible, regardless of the browser, platform or screen that your reader chooses or must use to access your pages.” His insights—published a mere decade after the invention of the medium—still influence the work I do to this day.

Aaron Gustafson, Web standards advocate at Microsoft


When “Dao” was first published, I wasn’t interested. I had no patience for it. I was too busy trying to make the web conform to my perfect and immutable designs. While it’s no surprise that 15 years ago I was dead wrong, it is pretty amazing to see how right John turned out to be.

Jim Coudal, Founder of coudal.com


John Allsopp’s essay rings true even today. I think to take it a step further would be to include printed pages in the scope of flexibility that web designers aspire to. My most challenging projects in recent years are the ones that run the gamut from screen to print—enabling people to create sophisticated print counterparts to their web creations from the same source file.

Rebecca Malamud, Founder of Point B Studio


If you’d told me 15 years ago that my pocket would contain a supercomputer powered by the web, I’d have thought you were crazy. Yet here we are: the flexibility of the web is enabling another wave of technological growth. And just as we fretted over content moving from the inflexibility of paper to our unbounded browser, some are concerned with apps becoming predominant. None of us knows how the next decade and a half will play out, but I feel certain the web will continue to find new and exciting ways to deliver content.

I just hope that I’ll still be able to enjoy my printed paper with a cup of coffee on Sunday morning.

Craig Hockenberry, Partner at Iconfactory


Designing for the web has always felt a bit like a double-edged sword. You don’t have complete control over every pixel, which felt like a limitation to me for a long time. But over the years I learned to embrace its flexibility, and to turn this limitation into a creative challenge. The web has never been as flexible as it is now.

Veerle Pieters, Founder of Duoh.com


The most elusive and often most desirable aim of any creative work is to remain relevant far beyond the period for which it was created. “A Dao of Web Design” is one of the very few documents in the volatile trade of technology that bears relevance not just a couple of years after its creation, but 15. 15! That’s an astounding testament of wisdom attributable not just to the document, but to its creator, too.

Cameron Moll, Founder of Authentic Jobs

“The web’s greatest strength, I believe, is often seen as a limitation, as a defect. It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.”

John’s insights are as sharp and relevant as ever, especially when we realize the web’s inherent flexibility isn’t just about layout—that, in fact, layout flexibility is one of the web’s least important features. I try to reread “A Dao of Web Design” at least once a year. You should, too.

Eric A. Meyer, Cofounder, An Event Apart and author of CSS: The Definititive Guide


15 years ago, I was struck by the poetry and simple truth of “A Dao of Web Design.” Little did I know that not only would the article still be relevant a decade and a half later, but it would essentially become our primary job. If there is one underlying theme to what we do for our clients, it is helping them let go of their perceived control and building a web that embodies the principles John espoused.

Jason Grigsby, Cofounder of Cloud Four


The web has changed a lot in the last 15 years, and in that time we’ve learned that embracing the web’s flexibility really is a requirement to do our jobs well.

The tension between wanting control and at the same time realizing we don’t have it drives us to come up with creative design solutions. It’s a big part of what makes working on the web interesting to me. The journey, as John so aptly calls it, is ongoing.

Val Head, Designer and author


15 years ago, the “Dao” encouraged web designers to find harmony around the inherent characteristics of the web, which posed distinctly different problems than print design. There is a great deal of energy currently being spent on redefining those characteristics in response to today’s shiny new problems—juggling complex data, enabling real-time communication, supporting multi-device interactions. Opinions about where the web is going next, and the frameworks and tools to get us there, arrive at a fast pace. But in a world that contains so much that is new and shiny, we must be careful not to misidentify our projects as different than what has come before—when more often than not we are still building for the web described by the “Dao.” A web of living documents, not living data.

Chris Casciano, Director of interface development at The Line


It’s very rare that a post withstands the test of time and becomes even more clairvoyant as it gets older. At the time, the “Dao” challenged all of our tools, assumptions, and addictions to pixel-perfection. But here we are, 15 years later, clinging to its advice like a prodigal child. I’m sure that web design has many more twists and turns in its future, but to me the “Dao” also lends testimony to thoughtful blogging: our ideas can find life and inspire over and over again in ways we could never imagine.

Dave Rupert, Lead developer at Paravel

  “What I sense is a real tension between the web as we know it, and the web as it would be.”

I think we have moved on to a new tension that consists of the web as we know it and the web as it should be. I know I am being naive and incredibly optimistic to consider the possibility that the web can reflect more of what is highest and most noble about humanity as opposed to what is depraved or vulgar or just plain mean. Let’s envision a day where we can see the world through this taoist precept: “From wonder into wonder existence opens.”

Debbie Millman, President of Sterling Brands


Because of foundational advocacy and application (through practices like progressive enhancement and responsive design), the web is more adaptable today than it was 15 years ago. With easy-to-use templating frameworks, it’s easier than ever to provide flexible layouts.

Unfortunately, over the last 10 years, we’ve seen the open system that is our internet fenced in—made less adaptable through design. The protocols are still open—HTTP, SMTP, etc. However, the designers of systems like Facebook and mobile apps decide how we can share (or not) with others. So, in many ways it feels like we’re going backward to the days of AOL and CompuServe.

I <3 the internet because it connects people and changes our perspectives and, thus, our minds. Through embracing adaptability (and openness), we unleash the power of the internet and ourselves.

Heather Hesketh, Founder of hesketh.com


John’s brilliant piece asks us to stand back and look at our work in a fresh way each day: questioning, yielding, breaking down walls, and always learning. Rereading it always inspires me to be better at what I do. He helped show us a critically important path: we can always be more of a community than an industry—even when commerce is what allows us to stay. The web is information, but the web is also communication. This “Dao of Web Design” is part of what makes us truly love what we do. As the web becomes a rant machine, a fire hose, a tool of oppression, an industrial outlet, beneath it runs the quiet river of the “Dao”—urging us to preserve what is beautiful and radical about creating the web and nudging us toward humility, empathy, and inclusivity. It’s about more than code: it’s a call to make an open web for every person on earth, to empower us all and allow every voice to be heard.

Carolyn Wood, Copywriter, brand/content strategist


“Dao” challenged me to look at accessibility and limits in a completely new way. No longer could I focus on just removing barriers for people with disabilities. I became an advocate for deeply satisfying design for all users, refusing to let the limits of accessibility restrict the experience for users without disabilities.

Glenda Sims, Team A11Y lead at Deque Systems


Accessible design is design for everyone. And if there’s anything that embodies the true essence of the web, regardless of metaphor (the page or whatever), it’s this guardianship each of us inherits when we design things for people. In spite of the caprices of technology and taste, we can still control how broad our understanding is. And that’s what I strive for, anyway—honoring my guardianship. If I can do that with sincerity, then I think I’ve done the web right. This is the lesson I learned from the “Dao,” and one I hope it continues to teach, gray-haired as it is now.

Michael L Johnson, Design director, Happy Cog


We no longer worry about browsers with insufficient support for stylesheets, or the difference in dpi between Mac and Windows. Making a site appear identical everywhere finally bit the dust with the advent of the iPhone.

We’re still working on making sites more accessible and adaptable—which is what really matters.

While the minutiae of web design have evolved over the last decade and a half, the goal—the road—the way—the “Dao” itself—has not changed. We’re further down that right path, and “A Dao of Web Design” helped illuminate the map.

Dori Smith, Author and programmer


“A Dao of Web Design” outlined a philosophy that today holds more true than ever.

Just as art imitates life, accessibility—the very foundation of the web—is direly needed beyond the web. It’s not only the guiding principle for interactive experiences on both smartphones and big-screen TVs, but for our societal development.

In a world where 1.3 billion people still lack access to energy, social networks are blocked at the whims of leaders with dictatorial ambitions, net neutrality is at serious risk, and a gazillion frameworks and conflicting standards are in use for web development—a relentless focus on accessibility (to energy, information, entertainment, different devices) will make sure that everyone is included.

We build the world we live in. Let’s make it accessible to everyone!

Pär Almqvist, Chief marketing officer at OMC Power, Owner and creative director at Cultivat3


I remember reading John’s article when it was first published and emphatically exclaiming “YES!!” to the idea of embracing that the web is not a fixed medium, unlike any of the dead-tree formats we have. Designing and building with flexibility in mind from the get-go helps ensure, and may even be critical to, transformability. That transformability may be represented by a simple change in browser viewport width, or containers that respect text resizing, or something more complex like text-to-speech from a screen reader, or completely overriding the author’s style suggestions with a user stylesheet. To me, when we design with flexibility and transformability in mind, we’re making a statement: that we believe the web is for everyone. John’s article and thinking helped set that fundamental belief for all of us in this profession.

Derek Featherstone, Team leader and founder at Simply Accessible


Although there’s only one web, it appears in many guises. Every browser/OS-combination is one such guise, and it frequently gets more complicated than that, especially on Android. Our job is to accommodate all of them.

Too many people new to web development (and that not only means new programmers, but also people coming from server-side programming) think they create an application for the web platform, singular, while in fact they create it for web platforms, plural.

Most other types of applications run in only one single environment, or at most a few. Not so the web: it runs in more environments than you can imagine. This is the next lesson we must learn. We work in many browsers, not in the browser. We run our apps on many web platforms, not on the web platform.

Let go of the singular. Embrace the plural. That’s what the “Dao” teaches me.

Peter-Paul Koch, Owner, QuirksMode.org and author of The Mobile Web Handbook


It used to be that only forward-thinking web designers—the kind of people who read A List Apart in 2000—cared about designing sites that took advantage of the medium. Now, responsive design is taught to beginning web designers, and clients and users expect it.

A fundamental next step is making our content responsive, not just the design. We’re starting to see this with things like Google Maps, which assembles a map on the fly based on your zoom level and viewport orientation. Personally, I’m trying to do it with music notation. And I want to see somebody do it for text—trim unneeded words and sentences depending on the reader’s knowledge or allotted reading time.

Responsive content is a harder problem than responsive design. It’s about algorithms, domain-specific knowledge, and something approaching artificial intelligence. But when we get there, it’s gonna be great.

Adrian Holovaty, Django co-creator, developer at Soundslice


I feel like every conference talk I give these days is a variation on principles articulated in “A Dao of Web Design.” It comes up on most episodes of The Web Ahead. We are inventing a powerful new medium. What a crazy journey and privilege. And yet we don’t fully understand this thing, even two decades in. We still attempt to design sites like they are print publications, using software from print design, drawing on paper of a fixed size with hard edges. In a new trend, teams manhandle the web with JavaScript, attempting to make it behave like a single-platform application environment.

Despite the passage of 15 years, the vision John articulated is more relevant than ever. We have more success on the web when we remember that the web’s strength comes from its inherent interoperability. The web was built to work on a wide range of computers and screens, across an extremely wide range of input and output options—across time itself. A website is a dynamic creature. Your content will morph in all sorts of unpredictable ways. John’s prescient article inspired us to lean into these qualities of the web. Not to fight them.

(Note: Eric Meyer and I interviewed John Allsopp for The Web Behind, where we talked about “A Dao of Web Design.”)

Jen Simmons, Host and executive producer of The Web Ahead

Categories: Mobile learning

Designing Social Tools for Tweens

A List Apart - Fri, 04/03/2015 - 12:30

Designing any type of online social experience for kids is a tricky business. You need to strike the right balance between fun and private, personal and respectful. This becomes especially important for kids in the tween years, ages 8–12, as they are just starting to recognize the vastness of the online space. In my years of designing and researching with kids of this age group, I’ve found that the best way to design for these types of interactions is the FRESH method:

  • Fast
  • Rewarding
  • Easy
  • Safe
  • Human

Let’s take a look at what that means in practice:

Fast

Kids and tweens are busy. Between karate class and soccer practice and music lessons and sleepovers, they’re always on the go. So when designing social interfaces for these folks, you’ll want to make sure that all interactions can happen quickly. This is an important differentiation from other types of games and apps for kids in this age group, where speed plays less of a factor. In my experience, I’ve found that kids generally like to take it slow with their screen time, focusing on every tap and click, enjoying the journey as they go. Not so for social interactions. These kids aren’t laboring through Facebook reading status updates and playing games, they’re taking photos and videos on Instagram, sharing them, liking them, and editing them.

Why is speed an important consideration for social interactions? Because, like adults, kids think of socializing as an “in the moment” type of construct, where they capture ideas, thoughts, images, and interests in real time and share them, much as they would in person. In fact, apps like Vine and Instagram have started serving as a secondary “lunch-tables” where kids communicate with each other and comment on each other’s experiences.

When designing these types of social tools, focus on the quickest path to sharing. Can you do it in one click? A single tap? Can you tighten the sign-in flow so it feels secure (safety is also important for kids) yet resolves quickly? These are important considerations for kids as well as adults.

Rewarding

This “R” could just as easily stand for “rush,” as in adrenaline. Kids as young as six are drawn in by the allure of online interactions, and love the excitement that comes from sharing something online that could be seen by thousands of people, if not more. The irresistible forces of seeing and being seen prove even more compelling as kids get older and more aware of their place within the world around them.

You can ensure the systems you design for kids are rewarding by throwing in some extras, not to slow down the process, but to heighten the excitement. For adults, the excitement comes in seeing the results of what they share, but for kids, the excitement comes from the sharing itself. Make that “share” button big and bright and enticing. Throw in some crisp, catchy text while the image or comment is loading, like, “Your genius is being shared!” And, when the upload is complete, choose cool, branded imagery as well as text to communicate the greatness of the child’s accomplishment.

Easy

Sounds like a no brainer, right? Social systems have to be easy to use. This is especially true when designing for tweens, however, because they have no patience for tools that are hard to learn. When designing for adults, we can sometimes get away with more complex online social interactions, because the value proposition of communicating online is much higher, especially when it’s for business, finance, or medical reasons. Since there are few “make-it-or-break-it” situations like this for kids, where they absolutely, positively have to get it right, they’re quicker to abandon tools that seem hard.

An exception to this is when kids are joining an existing online community that their friends are already using. In that case, they’ll be more likely to put the work in to figure out how to use it.

Safe

Unlike teenagers (and some adults), kids ages 8–12, for the most part, are focused on online safety. They don’t want to remain anonymous, necessarily, but they don’t want strangers to be able to find them or comment on what they share. This concern for safety likely comes from the admonitions of parents and teachers—usually starting around second grade when kids have more independence online—to “be careful,” “stay safe,” “pay attention,” and, the scariest, “go find a grownup if someone makes you feel unsafe.” When kids get a little older and figure out how to navigate the online world, they tend to be more carefree, and when they become teens, they start taking deliberate risks.

When designing social experiences for these tweens, set up all defaults to “private,” and then allow kids and parents to make changes on a case-by-case basis. Want to share a photo with grandparents? Select their email address from a list (or enter it and save it for future use). Want to share with friends? Enter their usernames (most kids under 12 won’t have an email address, and if they do, they won’t know it offhand). Want to share something with a wider audience? Remove everything but your first name and location. Don’t want negative feedback? Remove commenting ability. This will make kids as well as parents feel more comfortable with your tool.

It’s also a good idea to not allow tweens to be “findable” within a system, meaning that they have to share their actual usernames with their friends to get connected. These guidelines work if you’re designing a system to be used by both kids and adults as well.

Human

When you’re designing an experience that allows for any type of sharing, make sure you focus on positivity and eliminate any perception of judgement or negativity. Even a basic system that allows for simple “likes” or “thumbs-up” can be problematic, as kids take it very personally when, in their mind, they don’t get enough likes. Take a humanistic, communal approach when designing for these folks. You can show users the number of people who have viewed their image, post, or comment, but don’t allow others to judge the quality of the item. It’s best to remove anonymous feedback mechanisms for kids, as people tend to be more positive in their feedback when their comments can be traced back to them. 

For some good examples of tween-friendly social design, check out apps like Storybird, DIY, and Poptropica. Designing social components for kids, especially ages 8–12, is a slippery slope. It’s always best to get user feedback early and often while designing any type of interface, but using this FRESH method as you design will help you focus on the most important aspects of social interaction that have meaning to kids at this age.

Categories: Mobile learning

This week's sponsor: HipChat

A List Apart - Thu, 04/02/2015 - 14:14

Thanks to HipChat for sponsoring A List Apart this week! They’ve combined group chat, 1-on-1 chat, file sharing, screen sharing, video chat, and audio calls, all into one application.

Categories: Mobile learning

SMS Thought Leadership Series: How to Make Your Health-Related Text Messages More Effective

Mobile learning from MLearnopedia - Wed, 04/01/2015 - 15:51
'Text messages can be of great value in offering support for managing chronic conditions, changing behavior, or even saving lives. However, the way these messages are presented can make a big difference on the outcomes of its recipients. Here are the three strategies for writing effective health-related messages. is one example of an authority cue.

Brought to you by: Mobile Learning
Categories: Mobile learning

Initiation to Code

A List Apart - Tue, 03/31/2015 - 14:00

When you imagine a programming mentor, certain archetypes might flash into your mind. Maybe you see the wise monk who’s meditated on design patterns for decades. Perhaps it’s the sophisticated keynote speaker with a staggering list of open source contributions. Or it might be that mad scientist polyglot obsessed with a dozen languages you’ve never heard of.

But if these characters aren’t on your team when the new hire straight out of school joins up, who’s going to take the reins of training?

You, of course.

With the rise of coding boot camps and increased enrollment in computer science courses at universities, the pool of junior developers is larger than ever. But when it comes to nurturing all this talent, many teams don’t know where to start. Some developers think they don’t yet know enough to be a good mentor, while others think they’re just too busy for it.

Whatever your initial reservations may be, you can mentor, and you can do it well. All you need are the right guidelines and a little bit of structure.

Starting the mentor–mentee relationship

When you’re seeking a mentee, look for “someone who has something to teach you, but doesn’t know it yet,” as a friend of mine who mentors at RailsBridge recently suggested.

I take this to mean two things. The first is to stay open to a range of personality types. Look for a mentee who’s not similar to you. It can be tempting to compare juniors to yourself-three-years-ago and jump to conclusions from there. But mentorship is a two-way street—it’s not about lecturing. In fact, it’s not even about passing your knowledge down to another person. It’s about making a mutual agreement to get better at what you both do. You’ll learn more from each other if you have different ways of thinking.

The second is to choose someone you want to learn from. If your mentee isn’t the type of person you’d be happy to march into code battle with, you won’t get anywhere. The primary quality to avoid is arrogance; an arrogant person will have a slower rate of growth than someone who takes feedback gracefully.

Because team dynamics are constantly in flux, you might not often establish formal mentor–mentee relationships with people on your team. That doesn’t mean you won’t find opportunities to mentor. Look for little moments to step in and help; you’ll be viewed as a leader, and more mentoring opportunities will begin to materialize.

Agility is the key

The key to being a good mentor is a concept you’re already familiar with, since it’s also the key to developing good software and learning new information effectively. That key is agility.

Of course, “agile” has become a pretty loaded term that tends to confuse more than it clarifies. In a 2014 blog post, Dave Thomas, one of the original signatories of the Agile Manifesto, acknowledged this confusion. Then he reminded us how to do anything in an agile fashion:

  • Find out where you are
  • Take a small step toward your goal
  • Adjust your understanding based on your goal
  • Repeat

Or as the Scrum Guide puts it: “inspect and adapt.” Inspecting and adapting are foundational to being a good mentor. If you don’t take the time to check up on your mentees and listen to their concerns, travails, and triumphs, then you will have no metric for achievement.

Employing agility as a mentor requires sensitivity, creativity, and solid communication skills. It also requires the foresight to see what your mentee should be aiming for, and the hindsight to see what your mentee has already accomplished.

To establish a framework for gauging your mentee’s progress, consider the three phases every new team member goes through in some form. The first phase is total unfamiliarity and constant discovery; the second is a transitional period with a clear trajectory of progress; and the third is self-driven competence. In all three phases, remember that agility remains your most vital tool.

Phase 1: a little respect

On the very first day, have a conversation with your mentee in which your goal is to discover exactly what their level and type of experience is right now. This conversation serves a dual purpose. First, it establishes a two-way discourse, a communicative relationship that will underpin your agile approach to mentorship. Second, it gives you a basis to decide what to assign to your mentee first. Starting off with a direct conversation can prevent an incredible amount of confusion and wasted time.

Pair programming at this stage is pretty much mandatory. It’s far and away the best method for getting a new developer up to speed, especially if you have a large or confusing code base. A recent article by Sarah Mei makes some excellent points about how to pair effectively, but the most salient one is this: don’t touch the keyboard (much). Ask questions, and answer questions with more questions. The closer you are to your mentee’s level of experience, the harder it is to take the backseat approach, since you’re often just figuring things out yourself. But whenever you feel the urge to barge ahead and solve the problem, resist! Your mentee will learn much more effectively in the Socratic style.

Keep in mind, though, that you aren’t only a technical guide. Early on, gaining technical experience probably won’t be the first thing on a junior developer’s mind—much to their surprise. They’ll be confronted with social puzzles and process nuances that everyone else takes for granted. Clear away confusion over all the things surrounding the work so your mentee has no obstacles to digging down into the work itself.

As eager as you might be to keep things moving, make sure to be honest about your own limitations, too. Consider phrases like: “I don’t understand this, either.” “I need to take a break.” “I can’t help right now, but try asking Oleg.” All of these can be music to a beginner’s ears. The more truthful you are about when and how you and others can help, the more realistic your mentee’s outlook will be. And a realistic outlook leads to good decisions.

Phase 2: challenge accepted

With a solid communicative relationship established, your mentee will quickly move past the green stage. You’ll know that they’re in Phase 2 when they can easily figure out what needs to be done on a ticket, even if they don’t know quite how to do it. This means they’re starting to get comfortable, and it’s also when things get really fun. It’s time to add challenge to the mix.

Whatever you do, don’t simply assign your mentee whatever happens to come up. Instead, inspect, adapt, and select assignments that build on what your mentee has done before. If possible, try to tell a story with your assignments. Something in the next ticket could elaborate on or reinforce a concept from the previous ticket. Or you could tell the story of a single request, from UI to database and back again.

If you must assign your mentee something that looks relatively simple, use it as an opportunity to train them in looking at code with a pessimistic eye. What would a null input do? Does this open any vectors for attack? Could you have refactored another component to make this change easier? Do your tests cover all the new code? Even if your mentee decides that the code is airtight (which it never is), they’ll exercise their programming muscles trying to answer your questions.

While you challenge your mentee at every turn, don’t forget to take a lot of opportunities to encourage. A task that seems routine to you might feel like a triumph for your mentee, so when they finish something, congratulate them. And never underestimate the power of a simple “Good job.”

Phase 3: the initiation game

Your ultimate goal is to transform your mentee into a productive, contributing team member—an equal. With enough time and practice, they’ll eventually get there. But why wait? There’s a better, faster way. When your mentee is ready, you can help the transition along with a tool as old as humankind: initiation.

No matter who you are or where you’re from, you’re familiar with the narrative of initiation. Joseph Campbell identified it as one of the major elements of the hero’s journey, the underlying pattern shared by epic tales all across the world. From ancient mythology to pop culture mainstays like Star Wars and Fight Club, initiation stories have taken countless forms. The framework, however, is always the same: a harrowing ordeal that, if survived, yields the initiate to a new and higher level of awareness.

Initiation isn’t just for epic heroes. It’s a powerful tool for transformation in any context. When you feel your mentee is ready to take a big step, assign a task that seems a little too complex, a little too far outside the scope of what has been done before, and just difficult enough to accelerate the transition into an equal, independent team member.

An effective initiation for a software developer should have three qualities:

  1. It would not be trivial for someone with a few more years of experience.
  2. It demands communication with senior-level people. Ideally, the mentee will gain some insight into the factors that go into a high-level technical decision. Overhauling a UI component, modifying your deployment architecture, or hand-rolling a new caching strategy are all good candidates for this type of experience.
  3. It has a demonstrable, preferably quantifiable, value. It might be a new front-end feature, or it might be a graph that shows a decrease in page load time, but ideally, your mentee will be able to point to a visual representation of the change and say, “I’m responsible for that.”

Often, initiations are accidental, a natural outgrowth of increasing experience and responsibility. But if you do set up a conscious initiation for your mentee, you don’t need to tell them that you’re doing it. In fact, you probably shouldn’t. Show your mentee you believe in them by treating them like a regular engineer.

If the initiation is successful, your mentee will become an equal—though an equal who still has a lot to learn. They’ll be able to drive their own progress without much hand-holding, and pairing sessions will feel more collaborative than instructive. After this transition, you can take a big step back, but continue to guide and challenge when necessary. After all, as Robert Anton Wilson said, a true initiation never ends.

Mentoring benefits the whole team

When I first joined my team, I was the only junior developer. Now, our membership has grown and shifted, and almost half of us are juniors.

I’ve seen firsthand how much this shift has changed our dynamic for the better. Experienced engineers pose questions to the juniors, motivating them to refine their knowledge—and the juniors pose questions right back. Instead of a couple good communicators bearing the brunt of training, everyone is actively skill-sharing all the time. Where once individuals were siloed, there’s now a spirit of collaboration and fun. Willingness to learn and adapt has become a core value for the entire team.

It has also observably driven up our code quality. Fresh eyes are great at identifying anti-patterns, style issues, and confusing bits of code. With a healthy mix of juniors, we’ve become better at balancing technical debt repayment and pushing out new features, and the new code we merge is easier to maintain. Without mentorship, these improvements would never have come about.

Software engineers are fortunate to work in an industry where the tools and processes for collaboration are both well-defined and popular. But to paraphrase the Agile Manifesto, it’s the people and interactions that really make or break a product. Mentorship is a powerful interaction that, done right, can elevate your team’s quality of both life and code, and lay the groundwork for a more successful organization.

Categories: Mobile learning

Let Links Be Links

A List Apart - Tue, 03/31/2015 - 14:00

The concept of the web as an application platform has never been more popular, but the tools used to create these so-called “web apps” are still fraught with pitfalls that are often ignored or misunderstood. Single-page web app frameworks have gained traction because they can easily be used to create fast, complex applications that feel much more solid and interactive than traditional websites. But this benefit, and the changes in mindset and development practices that accompany it, comes at the cost of basic browser functionality that web developers sometimes take for granted.

JavaScript can be fragile

With vendors making it increasingly difficult to disable, we can get lulled into thinking that we don’t need to provide a fallback for users whose browsers don’t execute JavaScript. But explicitly choosing to disable JavaScript is far from the only reason a user’s browser might not run it. Government Digital Service (GDS), the team that maintains the UK government website, found that, out of every 500 visitors to GOV.UK, five did not receive JavaScript, but only one had JavaScript explicitly disabled. The other four could be missing out on JavaScript for any of several reasons: an overzealous corporate proxy server; a request for JavaScript timing out due to high latency; or even an unnoticed syntax error.

Furthermore, JavaScript—unlike CSS and HTML—does not degrade gracefully. This means that if developers use a single ES6 syntax feature, or even make a single standard library function call without checking that the function has been defined first, their JavaScript could either stop running midway through execution or not run at all. When JavaScript is used to enhance websites, this doesn’t matter so much—visitors can still follow links and submit forms and generally use the web as intended. But when JavaScript is a requirement, anyone using even a slightly older browser is likely to get a blank page—and no explanation of what to do about it.

Semantic structure is still important

As designed by Tim Berners-Lee in 1993, HTML defined a common structure for the mesh of interconnected documents we now know as the web. The semantic meanings imbued in this common structure provide machine-readable context for the information contained in a web page. In practical terms, this extra information enables web browsers to enhance the user experience. For example, a web browser can implement a way to add events defined with time elements to a user’s calendar; a screen reader can read through a list differently than it would a paragraph. The difference between a list and a paragraph is clear to human viewers of a document; the common structure provided by HTML makes it clear to computers, too.

The semantic meaning behind HTML sets the web apart from native application environments like Cocoa, Windows Presentation Foundation, and Qt. Structured information matters more to the web because of the diverse ways in which it can be accessed. When I create an iPhone application, I can safely assume that every person using that application will use it in a similar way. The information my app presents will always be presented in much the same way, and I will always have complete control over that presentation. Even if someone using my app interacts with it through VoiceOver (Apple’s assistive technology for people with vision impairments), they still interact with the application in a similar way to a sighted user: by tapping around on the screen. They just happen to be hearing the text instead of seeing it.

The web doesn’t work that way. Websites aren’t viewed solely through web browsers. People consume websites through apps like Pocket or Instapaper, which try to use the structured information of a web page to extract its relevant content. A browser on a smartwatch might ignore your layout and present your information in a way that’s more suitable for a one-inch screen. Or—who knows?—your website might be used through some future device that will transform the information into thoughts beamed directly into a user’s brain. Even web screen readers don’t work like VoiceOver does on an iPhone, reading out the text in the order it’s laid out under a user’s finger. Web screen readers read through the whole document, ignoring layout, and infer meaning from the standardized semantic definitions of HTML tags. A simple example of when semantics like this matter is the recently introduced main element, used to define the main part of a document. To a sighted user viewing your website through Google Chrome, whether you use <main> or <div id=“main”> makes no difference. To someone using another web client, though, such as a screen reader or Instapaper, the meaning implied by the main element is very important to their software in helping them navigate your document.

Developing an application for the web, therefore, is not as simple as developing for a native platform. Making sure it works the way we want it to in the five major browsers and pushing it out isn’t good enough for the web. We need to test our work in screen readers. We need to review our markup to make sure it provides as much semantic metadata as possible—not just for today’s web clients, but for tomorrow’s as well.

Single-page web app frameworks

When using “single-page web app” frameworks like Angular and Ember, the trend is to treat websites like native apps, with little regard for the nuances that make the web unique. Developers make assumptions about their users that can seriously damage the experience of people who don’t meet those assumptions. As an example of what this mindset can result in, consider the markup for a login button (since changed) that I recently found on Patreon’s site:

<span class="patreon-button sub-section navigation-active" data-ng-click="triggerChangeWindow(navigation.login_url)">Log In</span> Patreon’s fairly standard login button acts just like a link. No need for special JavaScript here.

This link works fine for me in Safari, but in any environment other than a current mainstream browser, this button is totally useless. Let’s say we have a hypothetical smartwatch browser called WatchBrowse. Maybe it displays a list of links for the user to navigate through because this particular smartwatch doesn’t have a cursor that can interact with the page. Because HTML defines a standard way to create links on a web page (the a element), WatchBrowse could theoretically just list every a tag on the page with its href attribute and content—until a site like Patreon comes along and decides to shun web standards in favor of reimplementing basic browser functionality from scratch.

If Patreon had used an a tag instead of a span, WatchBrowse could perhaps find the link and display it in the list. When a user selected the link, it could simulate a click event instead of just using the href attribute. But what about functionality that requires the browser to know where the link is going to lead ahead of time? A browser extension might allow you to search links on a page by their href values, which would be useful if you wanted to quickly find where somebody links to their Twitter account, for example. Firefox shows where a link is going to take me when I hover over it. When link href attributes are no longer static values but are, instead, decided by arbitrary JavaScript in click handlers, these helpful features are no longer possible.

Patreon’s site is built with Angular, and while Angular is not at fault here per se, the mentality of treating HTML as a view layer that goes along with using these frameworks probably contributed to Patreon’s poor decision.

What if we created the same link the way the framework developers recommend in their documentation? A more standard way to make a link in Angular might look like this:

<a ng-href="/login">Log In</a>

When rendered into the DOM by client-side JavaScript, that snippet turns into this:

<a ng-href="/login" class="ng-binding" href="/login">Log In</a>

Ember handles this similarly. A link is defined in an Ember template like so:

{{#link-to sessions.new}}Log In{{/link-to}}

And when it’s rendered into the DOM, it becomes this:

<a id="ember-563" class="ember-view" href="/sessions/new">Log In</a>

Ember and Angular then intercept the link’s click event to render the new content without reloading the page. Crucially, though, if the click event were never fired and the browser loaded the value of href, there would be no visible difference to the user other than an extra page reload, because Ember and Angular by default don’t try to reinvent the wheel by defining their routing in terms of URLs.

In their current forms, however, Ember and Angular still require JavaScript to render their templates and create those links in the first place. Four out of every 500 people who visit a website built with Angular or Ember will encounter a completely blank page.

A solution?

When dynamic web page content is rendered by a server, rendering code only has to be able to run on that one server. When it’s rendered on a client, the code now has to work with every client that could possibly visit the website. Developers are now moving away from server-rendered websites because they don’t offer the sort of rich application experience that client-rendered sites can provide. But I think there’s still a role for server rendering in the new world of client-side applications.

At the moment, requiring JavaScript is a tradeoff that developers using single-page web app frameworks have to make, but it seems to me that this is exactly the sort of problem that should be handled by a framework. We are fortunate as web developers in that we write application code for the web in one of the most universal programming languages that has ever existed. If framework developers could put in the effort (which, admittedly, seems large) to get apps running in Node just as they run in the browser, initial page rendering could be handled by the server, with all subsequent activity handled by the browser. Crucially, if a server can render links into a tags, like Ember currently does on the client, it would be possible for a user who did not receive JavaScript (for whatever reason) to navigate around the website. It might be possible to get forms working as well, by running all the validation and submission logic on the server instead of on the client. If this effort could be made at the outset by a framework maintainer, then every developer using that framework could immediately transform an app that only worked on the latest web browsers into a progressively enhanced experience compatible with virtually any web client—past, present, or future.

Progressive enhancement has been important to web developers for a while now. It recognizes that the vital part of the web experience is content, and that any additional improvement to the user experience should not undermine the universal availability of content provided by the web. Current approaches to single-page web apps tend to abandon this principle, but progressive enhancement and single-page web apps are not fundamentally incompatible.

In fact, progress is being made in this arena. To improve Ember’s compatibility with search engines, for example, an in-house team is working on implementing server-side rendering. But the solution to the problems caused by single-page web apps is not purely technical: there’s a growing problem in the way people think about the web. It has become commonplace to treat the web as just another application platform—but the web is so much more than that. The web is the universal information platform. It doesn’t matter if somebody visits a website on a $2,000 iMac, or a $50 Android tablet, or the $5 web client of a future we can’t even imagine yet—in theory, at least. In practice, it’s important to make sure that we don’t sacrifice the experiences of a small number of users just so we can slightly improve the experiences of the rest, damaging the universal nature of the web in the process.

Categories: Mobile learning

3 Reasons Why You Should (And Shouldn’t) Gamify Your Mobile Apps

Mobile learning from MLearnopedia - Mon, 03/30/2015 - 19:30
'Get the full Slideshare presentation from Scott’s presentation on using game elements in mobile learning apps at Learning Solutions 2015. Conferences Mobile Apps Mobile Strategy gamification Learning Solutions

Brought to you by: Mobile Learning
Categories: Mobile learning

SMS Nation: Mobile Strategists, Renewing Library Books, And Child Services Support

Mobile learning from MLearnopedia - Mon, 03/30/2015 - 19:11
'It’s not really news that text messaging is now a major communication channel between organizations and consumers. Here are three interesting and recent uses cases of text messaging around the nation today. Mobile strategists are the hottest new hire. What exactly are these new hires responsible for?

Brought to you by: Mobile Learning
Categories: Mobile learning
Syndicate content