Feed aggregator

On Our Radar: Self-Centered Edition

A List Apart - Fri, 03/27/2015 - 16:29

Okay, we admit it: it’s all about us. From steps to sleep to social activities, we’re counting every kind of personal data you can think of. But what’s all that data add up to? How could we look at it—and ourselves—differently? This week, we’re asking ourselves—and our self—the tough questions. 

My so-called lifelog

While waiting for an invite from gyrosco.pe, which promises to help me lead a healthier and happier life by harnessing my personal data, I started reading about life resource planning: the idea that we can administer every aspect of our lives using our timeline, our life feed, as a tool. LRP isn’t just the lifelogging data gathered by all the apps we use (health, finance, commuting, social graph, etc.). It’s about a user interface to make sense of it—a personal agent telling my story.

This has me thinking, how can I ever reinvent myself if my life feed becomes part of a documented history? The answer seems to lie in the notion of storytelling, becoming active autobiographers ourselves, using the same tools that tell our history, only to tell it better. When people are prompted to “tell a story” rather than state “what’s on their mind,” a character emerges—a qualified self (as opposed to the notion of the quantified self)—that may defy “big” data.

Michelle Kondou, developer

Mirror, mirror

A couple of days ago, I came across dear-data.com, a project by data visualization pros Giorgia Lupi and Stefanie Posavec. Instead of building digital charts and graphs, they’re documenting details of their lives onto handmade postcards—translating quiet moments of the everyday into colors and lines of self-awareness, and reinventing the rules each week. With a flickering edge of whimsy and objectivity, those moments are real life—through a filter.

What I love about Dear Data is that their conditions create new filters; they end up with a different view of themselves each week. Getting out of their usual medium and having to create new ways to tell each story is a tactic for hunting down catalysts. I also like how they went to something so square one: paper and colored pens, no expectations to be fancy, no need for neat lines.

Dear Data has me thinking about how we can all gain momentum from reimagining our digital selves every once in a while—from ditching our habitual means of describing and defining. How I can so easily show myself a new mirror and allow a situation to filter through me—I’d discover a different result each time. Those moments are grounding: they’re a sharp instant of humility, a moment of recognition that you’ll never see anything in the same way again.

Mica McPheeters, submissions and events manager

My birthday, my self

Ah, spring—that special time of year when a young developer’s fancy soon turns to thoughts of lexical scoping, and I’ve got ECMAScript 6 arrow functions on the brain.

Defining a function as usual introduces a new value for the this keyword, meaning we sometimes need to write code like the following:

function Wilto() { var self = this; self.age = 32; setInterval( function constantBirthdays() { self.age++; console.log( "I am now " + self.age + " years old"); }, 3000 ); }

Since the meaning of this is going to change inside the constantBirthdays function, we alias the enclosing function’s this value as the variable self—or sometimes as that, depending on your own preference.

Arrow functions will maintain the this value of the enclosing context, however, so we can do away with that variable altogether:

function Wilto() { this.age = 32; setInterval(() => { this.age++; console.log( "I am now " + this.age + " years old"); }, 3000 ); }

Thanks to ES6, we can finally start getting over our selfs.

Mat Marquis, technical editor

A gif about: self(ie) love Haters gonna hate.
Categories: Mobile learning

Free eLearning solutions at the Learning Exchange platform @eLearningGuild

Mobile learning from MLearnopedia - Thu, 03/26/2015 - 13:48
'The eLearning Guild has launched an interesting content creating and sharing program, called the Learning Exchange. The idea is simple: let your members share their expertise (fits any expert learning format). The nice thing is that we all get to know each other better, and it provides us a stage to share eLearning content that we make anyway.

Brought to you by: Mobile Learning
Categories: Mobile learning

Laura Kalbag on Freelance Design: The Illusion of Free

A List Apart - Thu, 03/26/2015 - 12:30

Our data is out of our control. We might (wisely or unwisely) choose to publicly share our statuses, personal information, media and locations, or we might choose to only share this data with our friends. But it’s just an illusion of choice—however we share, we’re exposing ourselves to a wide audience. We have so much more to worry about than future employers seeing photos of us when we’ve had too much to drink.

Corporations hold a lot of information about us. They store the stuff we share on their sites and apps, and provide us with data storage for our emails, files, and much more. When we or our friends share stuff on their services, either publicly or privately, clever algorithms can derive a lot of of detailed knowledge from a small amount of information. Did you know that you’re pregnant? Did you know that you’re not considered intelligent? Did you know that your relationship is about to end? The algorithms know us better than our families and only need to know ten of our Facebook Likes before they know us better than our average work colleague.

A combination of analytics and big data can be used in a huge variety of ways. Many sites use our data just to ensure a web page is in the language we speak. Recommendation engines are used by companies like Netflix to deliver fantastic personalized experiences. Google creates profiles of us to understand what makes us tick and sell us the right products. 23andme analyzes our DNA for genetic risk factors and sells the data to pharmaceutical companies. Ecommerce sites like Amazon know how to appeal to you as an individual, and whether you’re more persuaded by social proof when your friends also buy a product, or authority when an expert recommends a product. Facebook can predict the likelihood that you drink alcohol or do drugs, or determine if you’re physically and mentally healthy. It also experiments on us and influences our emotions. What can be done with all this data varies wildly, from the incredibly convenient and useful to the downright terrifying.

This data has a huge value to people who may not have your best interests at heart. What if this information is sold to your boss? Your insurance company? Your potential partner?

As Tim Cook said, “Some companies are not transparent that the connection of these data points produces five other things that you didn’t know that you gave up. It becomes a gigantic trove of data.” The data is so valuable that cognitive scientists are giddy with excitement at the size of studies they can conduct using Facebook. For neuroscience studies, a sample of twenty white undergraduates used to be considered sufficient to say something general about how brains work. Now Facebook works with scientists on sample sizes of hundreds of thousands to millions. The difference between more traditional scientific studies and Facebook’s studies is that Facebook’s users don’t know that they’re probably taking part in ten “experiments” at any given time. (Of course, you give your consent when you agree to the terms and conditions. But very few people ever read the terms and conditions, or privacy policies. They’re not designed to be read or understood.)

There is the potential for big data to be collected and used for good. Apple’s ResearchKit is supported by an open source framework that makes it easy for researchers and developers to create apps to collect iPhone users’ health data on a huge scale. Apple says they’ve designed ResearchKit with people’s privacy values in mind, “You choose what studies you want to join, you are in control of what information you provide to which apps, and you can see the data you’re sharing.”

But the allure of capturing huge, valuable amounts of data may encourage developers to design without ethics. An app may pressure users to quickly sign the consent form when they first open the app, without considering the consequences. The same way we’re encouraged to quickly hit “Agree” when we’re presented with terms and conditions. Or how apps tell us we need to allow constant access to our location so the app can, they tell us, provide us with the best experience.

The intent of the developers, their bosses, and the corporations as a whole, is key. They didn’t just decide to utilize this data because they could. They can’t afford to provide free services for nothing, and that was never their intention. It’s a lucrative business. The business model of these companies is to exploit our data, to be our corporate surveillers. It’s their good fortune that we share it like—as Zuckerberg said—dumb fucks.

To say that this is a privacy issue is to give it a loaded term. The word “privacy” has been hijacked to suggest that you’re hiding things you’re ashamed about. That’s why Google’s Eric Schmidt said “if you’ve got something to hide, you shouldn’t be doing it in the first place.” (That line is immortalized in the fantastic song, Sergey Says.) But privacy is our right to choose what we do and don’t share. It’s enshrined in the Universal Declaration of Human Rights.

So when we’re deciding which cool new tools and services to use, how are we supposed to make the right decision? Those of us who vaguely understand the technology live in a tech bubble where we value convenience and a good user experience so highly that we’re willing to trade it for our information, privacy and future security. It’s the same argument I hear again and again from people who choose to use Gmail. But will the tracking and algorithmic analysis of our data give us a good user experience? We just don’t know enough about what the companies are doing with our data to judge whether it’s a worthwhile risk. What we do know is horrifying enough. And whatever corporations are doing with our data now, who knows how they’re going to use it in the future.

And what about people outside the bubble, who aren’t as well-informed when it comes to the consequences of using services that exploit our data? The everyday consumer will choose a product based on free and fantastic user experiences. They don’t know about the cost of running, and the data required to sustain, such businesses.

We need to be aware that our choice of communication tools, such as Gmail or Facebook, doesn’t just affect us, but also those who want to communicate with us.

We need tools and services that enable us to own our own data, and give us the option to share it however we like, without conditions attached. I’m not an Apple fangirl, but Tim Cook is at least talking about privacy in the right way:

None of us should accept that the government or a company or anybody should have access to all of our private information. This is a basic human right. We all have a right to privacy. We shouldn’t give it up.

“Apple has a very straightforward business model,” he said. “We make money if you buy one of these [pointing at an iPhone]. That’s our product. You [the consumer] are not our product. We design our products such that we keep a very minimal level of information on our customers.”

But Apple is only one potential alternative to corporate surveillance. Their services may have some security benefits if our data is encrypted and can’t be read by Apple, but our data is still locked into their proprietary system. We need more *genuine* alternatives.

What can we do?

It’s a big scary issue. And that’s why I think people don’t talk about it. When you don’t know the solution, you don’t want to talk about the problem. We’re so entrenched in using Google’s tools, communicating via Facebook, and benefitting from a multitude of other services that feed on our data, it feels wildly out of our control. When we feel like we’ve lost control, we don’t want to admit it was our mistake. We’re naturally defensive of the choices of our past selves.

The first step is understanding and acknowledging that there’s a problem. There’s a lot of research, articles, and information out there if you want to learn how to regain control.

The second step is questioning the corporations and their motives. Speak up and ask these companies to be transparent about the data they collect, and how they use it. Encourage government oversight and regulation to protect our data. Have the heart to stand up against a model you think is toxic to our privacy and human rights.

The third, and hardest, step is doing something about it. We need to take control of our data, and begin an exodus from the services and tools that don’t respect our human rights. We need to demand, find and fund alternatives where we can be together without being an algorithm’s cash crop. It’s the only way we can prove we care about our data, and create a viable environment for the alternatives to exist.

Categories: Mobile learning

This week's sponsor: Inbound.org

A List Apart - Wed, 03/25/2015 - 16:08

Thanks to Inbound.org for sponsoring A List Apart this week! Check out their community where inbound designers, developers, and marketers come together to connect, learn, and grow.

Categories: Mobile learning

Now on-line: The "Mobile Learning Scenarios Weblog"

London Mobile Learning - Mon, 03/23/2015 - 15:31
In February 2015, members of the "Network for Mobile Learning Scenarios", which is a network of the London Mobile Learning Group (LMLG), launched the "Mobile Learning Scenarios Weblog". People interested in letting teachers, researchers and policy makers know about their mobile learning practice in formal and informal learning contexts are invited to submit their scenarios. Please spread the word!

For practitioners who want to realise mobile learning, but need a bit support are invited to use our template for planning and evaluating mobile learning scenarios. It is available in English and German language.

These are the aims of the Scenarios Weblog:
"The Network for Mobile Learning Scenarios, which is a sub-network of The London Mobile Learning Group (LMLG; www.londonmobilelearning.net), offers this page aiming to provide a rich resource of mobile learning practice for teachers, researchers, and policy makers.
For the Network, mobile learning is centred on the use of handheld technologies, such as Smartphones, iPods, tablet computers and the functions or apps utilized on these devices to augment and enhance learning objectives and activities. Mobile learning is, especially, the use of these devices beyond the classroom taking learning into the wider landscape, engaging with cultural and social institutions, field studies, networks or experts, as well as considering mobile technologies as part of users’ lifestyle choices and for media consumption, different social contexts and milieus in which people are learning, and the different demands of educational institutions and their policies.
The aim of the ‘Network for Mobile Learning Scenarios’ is to provide perspectives for the implementation of mobile technologies in teaching and learning contexts, be they formal or informal, during school or leisure, at work or at university, by providing ‘scenarios’ for learning and teaching. In contrast to large-scale projects scenarios can be understood as modular units which are replicable, scalable and transferable and apply to the use in specific learning situations. Part of the Networks’s work is the Mobile Learning Scenarios blog that was created to publish examples of mobile learning in current educational practice. It was designed by a pan-European collective of academic researchers wishing to disseminate these examples (scenarios) as both support for teachers and institutions in varying educational contexts and levels and to stimulate further research. The Network embraces the opportunity and potential of mobile technology as the basis of a Community of Practice. As such, we encourage open participation. A strong community learns together by virtue of its activity, so we welcome submissions from practitioners to showcase their use of mobile technologies to enable understanding of the significant experiences, and affordances, of mobile learning. Submissions to the blog facilitate the opportunity to share projects from international practitioners at all levels. This in turn helps to generate feedback, debate and stimulates further research into the paradigms that these dynamic technologies represent."
Categories: Mobile learning

Considerations for Equity and BYOD

Mlearnopedia - Mon, 03/23/2015 - 04:11
While many articles about BYOD focus on educational apps for Smartphones, it is fundamental that teachers take equity into account when planning for BYOD. Podcasting: Students call in a live podcast on a topic of research. Vision for K-20 Education : Results from the SIIA Vision K-20 Survey. 2013). 2013). is the most versatile!

Brought to you by: Mobile Learning
Categories: Mobile learning

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

Mobile learning from MLearnopedia - Thu, 03/19/2015 - 22:18
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

Matt Griffin on How We Work: Readable Wearables

A List Apart - Thu, 03/19/2015 - 12:30

A few weeks ago we added our first wearable to the Bearded device lab, and it was an eye-opening experience. The same day that Apple showcased the soon-to-arrive Apple Watch, a Samsung Gear S showed up at our door. This device is a large smartwatch with pixel dimensions slightly greater than the iPhone 3GS. It has Opera Mini and its own cellular and wifi connections, so it functions as a standalone web interface.

So will people use their watch-like devices for browsing the web? Though some may scoff at the idea (and believe me, there’s been plenty of scoffing), stranger things have happened. And if the last few years have taught us anything, it’s that if you can use something to get on the web, people will get on the web with that thing.

After some personal use, it seems to me that these watch-sized screens are a totally reasonable way to access web content. And it’s equally reasonable for us to present our content in readable ways on these screens.

As Brad Frost recently wrote, responsive design and future-friendly strategies go a long way to making sure our websites work and display the best they can on devices that haven’t even been invented yet. And it’s true that my first reaction to seeing the sites we’ve built displayed on the Gear was “not bad.” But, as I began to look closely and interact with these familiar sites via a tiny curved screen on my wrist, my perspective began to subtly, but significantly, shift.

My gut reaction to these new smallest-of-screens: I’ve been starting with too big of a browser window. Lucky for us, if we’ve been prescient enough to be writing our CSS in extensible ways (and goodness knows mobile has given us plenty of reasons to do this already), there’s some pretty great low-hanging fruit for us to grab.

The current Bearded site is super simple; a static two-pager with no navigation and very little in the way of bells and whistles. It struck me as a perfect candidate to try out some wearable-friendly optimizations without a lot of distractions. So let’s have a look at what could be done in an afternoon to make it more pleasurable to read on a watch.

Let’s get small

The Samsung Gear S, according to my tests, registers with media queries as a 213px-wide viewport. This is a far cry from the 300px-wide starting point I’ve become accustomed to when styling.

On this new screen size, the range of acceptable type sizes is tighter than what I’ve been used to. My type was mostly either huge and unwieldy or eye-strainingly small. The original site styles utilized headings set in Quadon Regular, which range from 0.875em to 2.5em. But a 213px-wide viewport, to my sensibilities, only tolerates type sizes from 1.1em to 1.6em with that same typeface.

Boldly oversize type loses its appeal on the very small screen. (Left: before; right: after.)

A closing of the typographic aperture seemed called for, but how to do that without reworking a ton of CSS? Enter Past Bearded being kind to Future Bearded. Here’s how, thanks to Sass, we’ve been writing our heading styles for years. First we define the font stack:

@mixin title-face { font-family: Quadon-Regular, arial, “helvetica neue”, helvetica, sans-serif; font-weight: normal; }

Then we roll that mixin into our general heading mixin, where we add margin-bottom, line-height, and color:

@mixin heading { @include title-face; margin-bottom: 0.35em; line-height: 1.2; color: $heading-color; }

Next, we snowball all of that into the various specific heading mixins, and add font-size:

@mixin heading-1 { @include heading; font-size: 2.5em; } @mixin heading-2 { @include heading; font-size: 1.8em; } ...

Which we can apply to all our headings by default:

h1 { @include heading-1; } h2 { @include heading-2; } ...

This approach may at first seem a little overwrought, but it provides some terrific practical benefits over time. For instance, should you have something that semantically deserves to be lower down the chain from an h1 (say a paragraph or an h2), but you want it to have the visual appearance of an h1, you can just apply the heading-1 mixin:

h2 { @include heading-2; &.title { @include heading-1; }

Best of both worlds, right?

As is often only possible with Sass, this approach also abstracts major styling decisions away from the low-level CSS implementations. This allows for us to be more agile with changes, even later in the project when our CSS files have grown more unwieldy.

For our wearable type hierarchy issue, I was able to easily make adjustments to my heading sizes by adding media queries to those mixins, like so:

@mixin heading-1 { @include heading; font-size: 1.6em; @include breakpoint($breakpoint-s) { font-size: 2.5em; } }

Then I got to sit back, refresh my browser, and watch my sitewide heading typography do its thing. Past Bearded, thank you for being awesome.

Limitations breed innovation

The tiny screens of wearables further restrict the design options we have at our disposal, even more so than mobile screens did before them. But working within this more limited palette is not necessarily a bad thing.

In the letterpress world, for example, we’re restricted to the type we have physically sitting in our cabinets. The weights, sizes, typefaces, and variations we have to work with are extremely limited. And this can lead to some very exciting design work that otherwise we’d never be forced to do.

When we work to come up with a sensible typographic hierarchy for any size screen, we must first consider what we have to work with:

  • font-family
  • font-size
  • font-weight
  • font-style
  • font-variant
  • font-weight
  • text-transform
  • color

The most obvious things (aside from size) that you can use to accentuate your headings are uppercase and bold. Small caps, italics, a new font-family, or color changes may be reasonable options for you, as well.

Though you may not have enough variations in font-size between 1.6em and 1.1em to effectively distinguish six heading sizes from each other, you can mix up font size changes with other type qualities to have that effect, then shift back to your size-based hierarchy as screen size allows for it.

For instance, with the Bearded site headings I chose to use uppercase as a differentiator for two headings with the same font-family and font-size. Then, when the screen is wide enough, I can use media queries inside the mixins to return to my font-size based hierarchy, like so:

@mixin heading-3 { @include heading; font-size: 1.1em; text-transform: uppercase; @include breakpoint($breakpoint-xs) { font-size: 1.4em; text-transform: none; } } @mixin heading-4 { @include heading; font-size: 1.1em; @include breakpoint($breakpoint-xs) { font-size: 1.2em; } } Where’s that breakpoint gonna go?

Speaking of which, at what point should one add this no-longer-wearable breakpoint? The answer: at a width at which your larger screen design decisions start making sense again. The Gear clocked in at 213px, but it seems like those smallest-screen decisions would be beneficial for widths wider than that. When enlarging my browser up from 213px, my wearable-focused design decisions applied for the most part up until 290px, at which point typography could stretch out a little more, and some multi-column grid layouts could comfortably be put to use.

But not all of the layout decisions from the existing mobile-centric site design made sense at 290px. What’s interesting is that, working at that scale, I actually needed an extra breakpoint. Previously I’d been working with these breakpoints:

  1. < 400px
  2. 400px
  3. 550px
  4. 700px

Now, starting with smaller widths, I’d arrived at:

  1. < 290px
  2. 290px
  3. 350px
  4. 550px
  5. 700px

Not surprisingly, the smaller the screen, the greater the impact that a few pixels has. The difference between 1000px and 1050px may not warrant any design changes at all, whereas the difference between 250px and 300px almost certainly does.

Too small for small

The last thing I addressed was a bit surprising to me: my 1em (16px) body copy type was too small to comfortably read. I’ve always thought of 1em as a font size that was great for web reading. It feels almost clunky, in fact, when compared to the 8pt reversed type I frequently saw in the world of print design. But on this tiny screen on my wrist, there seemed to be a huge difference, at least with this font-family, between the 1em body type and the 1.1em intro paragraph copy.

Increasing the font-size from 1em to 1.1em helped readability. (Left: before; right: after.)

On this site, fixing that was a breeze—I could just increase the font-size of all paragraphs to 1.1em. There was no need to worry about accidentally missing anything, because there was no non-paragraph body copy (i.e. lists or tables). But for a bigger site, this would be too specific of a solution. I could easily end up with well-sized paragraphs and—on some forgotten page—a tiny definition list or errant span. So what might a more extensible solution look like?

Easy—we can just bump up the site-wide font-size for everything below a certain breakpoint! Something like:

html { font-size: 110%; @include breakpoint($breakpoint-s) { font-size: 100%; } }

Of course, now our small screen heading sizes are 10 percent too big. Oh man! Good thing we used those mixins, huh?

Thanks to the Sass-based typographic system we established earlier, adjusting those values a second time won’t be so bad. Who knows, we might even be in pretty good shape when those web-enabled holographic refrigerators finally hit the market in 2016.

Categories: Mobile learning

This week's sponsor: MyFonts

A List Apart - Wed, 03/18/2015 - 19:46

Thanks to MyFonts for sponsoring A List Apart this week! Take a look at their list of the 50 most popular fonts on the web.

Categories: Mobile learning

Don’t Forget About Contrast

A List Apart - Wed, 03/18/2015 - 12:30

Several years ago I wanted to get an external monitor to go along with the laptop my work provided. I was a remote worker and decided to buy one myself that I could hang on to even if I left that job. But I was also a bit cheap. I drooled over the Apple Cinema displays, but I didn’t want to spend that kind of money.

Enter the big-box electronics store and their wide range of displays. I stood in front of one, decided on a size, and purchased it. I bought an LG that seemed “good enough” for my need for more screen real estate for windows of code, browsers, and dev tools. To be quite honest, this monitor has met those needs. I’m still using it.

It also pointed out a glaring issue that rears its head in a lot of our designs: we aren’t using enough color contrast to accommodate users who may not have the latest and greatest screens. I surfed the web the way I think a lot of people do, on a monitor that they took out the box and started using without doing any calibration. I was astounded by the lack of contrast all over the place. We like gray a lot and often we like it to be very subtle.

So, even though this monitor is not exactly what I would have bought if I could have afforded something nicer at the time, I’m now grateful for it. While I’m working on client projects, I’m often pointing out to the designers when their design cues or colors may be a little too subtle. If I’m dragging a design over to my laptop screen to be able to differentiate the contrast and colors, then it’s probably a good idea to punch things up a bit.

You don’t have to go out and buy a cheap monitor to see this, you can also test on older devices that don’t have the latest and greatest screens on them. Many cities have Open Device Labs where you can test on devices for free. If something like that is unavailable to you, there are other ways to find devices for inexpensive testing—Brad Frost has a great post on how to do that. There are many instances where our sites or applications aren’t going to be used on high-end, Retina devices or monitors and I think we have an obligation to consider that as we design so all our users can easily interact with the things we build.

As an example of this, I recently worked on an application that was intended for use in hospitals. I couldn’t help but wonder, were those monitors going to be able to show subtle color differences? Many of us are making applications that may be used places like hospitals, or other settings where the screens being used aren’t calibrated to perfection so subtle contrast can get lost. That’s just one example of an audience where I would want to be careful about what I expect out of a screen or monitor.

If you don’t have a cheaper monitor around, I highly recommend using developer tools to help you check for accessibility issues such as contrast. The accessibility team at Google has been doing a great job making tools that can help point out where there may be issues, so if you use Chrome, run an accessibility audit to see where you may need to make changes. Jenn Lukas wrote a great blog post here on ALA to describe testing color in the Chrome Dev Tools.

I’m grateful for this monitor because it points out contrast issues and reminds me frequently that those issues exist, and like color blindness variations, need to be taken into account as we work. Color contrast plays a large role in our designs, so make sure you test for it, check out designs on less capable screens, and audit your sites with the tools available, so that your users can easily see all the pieces of your design.

Categories: Mobile learning

80/20 Practitioners Make Better Communicators

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

I spent the better part of 2014 working on two redesigns: one for a major pizza chain, the other for a major bike retailer. The five of us working on the redesigns were excited beyond words—two large-scale sites about two things we loved: pizza and bikes! We all wanted to be heavily involved in every phase of these projects to ensure their success. Along the way, we learned important lessons about how to fine-tune that involvement to arrive at a better outcome.

Working with the same team on two simultaneous projects allowed us to experiment a little with our process and compare notes. The ecommerce-driven Pizza Site had a strong focus on user flows, so we began by creating HTML wireframes for every page. What had once seemed like a bunch of grandiose ideas on whiteboards morphed into actual working prototypes. As we moved into design, the prototypes came to life in all their melted-cheese glory. But by month nine of the engagement, as we started to polish up the templates, we realized that we were looking at the third installment of the same redesign.

This isn’t an unusual occurrence. Teams often inadvertently recreate designs multiple times across phases; the end result looks almost nothing like what the team set out to achieve. What causes this disconnect?

In my experience, it comes from insufficient communication among teams with varying skillsets. Some teams are composed of specialists who all want their ideas and voices heard (yielding vastly different results) while fighting for time, resources, and budget. Alternately, when a generalist works on the entire site, they risk getting spread too thin; the struggle to explore and iterate can produce stale, predictable solutions. Either too much specialization or too much generalization can overwhelm practitioners (and budgets)—and neither approach works.

How to become an 80/20 practitioner

Luckily, there’s a better way. When designers and developers (and entire web teams) work closely together with flexibility and shared understanding, they can use their time and resources more efficiently and creatively. Whether your process is waterfall or agile, a solid team foundation applies to everyone: it allows you to shape a solution that benefits all teammates on a project.

To avoid the mistakes we made on our Pizza Site process, we balanced our responsibilities differently with the Bike Site. We became what I call 80/20 practitioners, focusing 80 percent of our time on our own respective strengths while distributing the remaining 20 percent across other disciplines to benefit the entire project.

80/20 collaboration is about people. It’s about passions. Sounds great, right? So, where do we start?

Establish the foundation

Being a good practitioner means seeing beyond yourself to your team’s broader needs and goals. While molding your process, it’s important to maintain an open, honest discussion with your teammates. Take a comprehensive inventory of the people on your team. Instead of labeling someone a “designer” or a “developer,” take stock of their true skillsets and passions. I’ve worked with amazing graphic designers, amazing UX designers, and amazing interaction designers, all of whom had the same title: designer. What works depends on the person.

We’ve all heard the argument that designers need to code. And while that might be ideal in some cases, the point is to expand your personal spectrum of skills to be more useful to your team, whether that manifests itself in the form of design, content strategy, UX, or even project management. A strong team foundation begins by addressing gaps that need to be filled and the places where people can meet in the middle. This is also how you, as a practitioner, can identify where you should develop your 20 percent of surplus abilities for a given project.

If you imagine your team as a spectrum of skills, each person should have a skillset that covers one part of that spectrum (overlapping to some extent with another part). Let’s pretend this spectrum goes from graphic design (red), to code (blue), with every shade of purple in between. As a designer, I span from the reddest of reds to a reddish purple. That leaves the rest of the purple and blue to be picked up. Let’s say my team includes a designer/developer hybrid, Ava, who is all the varying shades of purple. And let’s say I also have a strictly blue backend developer, Carter, on my team. In this instance, we’ve covered all our bases. If it was just Carter and me, though, we’d be left with a significant void in the middle. We would need either to extend our 20-percent skillset into the purple area or to bring in an additional person to bridge the gap. The spectrum’s endpoints will vary from person to person and team to team.

Strengthen weaknesses

Whenever someone told me, “You should code!” I would think: “But Developer McCoderson can do it so much better and faster than I ever could!” Which was true, so I continued my deep dive into design. Over time, though, working very closely with my developers every day on the Pizza Site, my interest was slowly piqued. Once I started incorporating HTML wireframes into my design process, I began to see how it benefitted me. I could make faster content updates, my layout was automatically responsive, and I could focus purely on content hierarchy rather than worrying about resizing boxes every time content changed.

The more I realized that coded deliverables could be design deliverables, the more I understood that I could get interactions in front of a client earlier. Animations, dropdowns, popovers, etc.—these things are design. We want the client’s feedback on this early, because seemingly minor details like hovers reflect the brand and reinforce the design just as much as an image or color choice do.

This discovery was so liberating that I actually wanted to include code in my process from then on because I preferred working that way, not just because I thought “This will make me a better designer.” I now catch myself voluntarily reading about things like inline SVG and the picture element and almost don’t recognize myself!

Take a candid look at your process and see where you want to expand your 20 percent, not where you think you should expand it. Let’s go back to Carter, the backend developer, for a second. Maybe he wants to improve his front-end skills—but by “front-end,” does he mean his code or his design eye? What’s missing is probably not a talent for writing beautiful DRY code, but rather the ability to recognize design nuances. Maybe the place to start is by reading articles about typography or checking out other design resources, instead of plunging into JavaScript.

Once you start recognizing these secondary areas, you can begin to take your newfound interests offline and look into different meetups or talks than you’d normally attend. I discovered that nothing helped me improve my 20-percent skills more than simply befriending wildly talented developers, both in and out of the workplace.

Learn from each other

The developer on the Bike Site team created a Grunt file to accommodate our entire team’s needs, including design deliverables and how we handle wireframes. Once everything started being delivered within a code-based project hub, we were all on the same page—literally. We could jump in and help each other as necessary, especially on stressful delivery days. Even the project manager was able to use and update the hub.

And the developers learned from me, too. Having them involved from day one meant that they were included in a lot of our design reviews. They began to understand the thought process behind our design decisions, and everyone could holistically understand the system we all were building together. When we began to figure out the wireframing and user-experience part of the site, every member of the team had behavior- and experience-driven suggestions that found their way into the project, both in terms of how it would ultimately look and how it would be built. With everyone involved from the beginning, new ideas that previously never would have been considered cross-pollinated the deliverables—whether it was a developer suggesting an out-of-the-box design pattern or a designer creating a performance budget.

When these conversations happen, barriers between teammates gradually fall away. You’ll probably suggest tools to one another and start to merge processes; in that merging, a new collaborative process will take shape. When we borrow one another’s tools, we begin to learn their benefits and how they may work for our own needs, and we ultimately start speaking the same language. Being aligned on objective project goals helps to keep reviews on track and to more easily settle discrepancies. It isn’t about making anyone’s job easier; it’s about focusing on what’s best for the project. Shared process isn’t something that you can just decide to do; rather, it emerges from learning how another person works.

Let go of ego

To rapidly take a design to code, the overall direction needs to be mostly approved by the client. I say “mostly” because the best iterations happen in the browser once we begin interacting with our designs. This is where our 20-percent-spectrum overlap really kicks in. There will be holes in the design that need to be filled, and it’s up to the developer to create a useful roadmap for the designer to iterate on. Imagine that an early homepage concept is approved and we jump into developmental iterations, but I haven’t had a chance to style the navigation dropdowns yet. I love it when developers take a stab at styling these things. If need be, I can always tweak details that feel off to me. When developers have some design sense, they are able to jump in and make design decisions that the designer may not have considered in a fluid layout or behavior. Designers love to be perfectionists, but we need to learn to let go and not be afraid to allow developers to jump into coding a template of an “imperfect” mockup.

There’s nothing wrong with piece-designing parts and modules as the developer finds holes in the page or media queries. As Dan Mall has stated, it’s about deciding in the browser, not designing in the browser. Everything might not be figured out yet, but that’s okay: we’ll figure it out together. Our websites are fluid; our process should be, too.

Shaking up a process isn’t easy

Change can be hard for any organization, especially when strict guidelines are in place for current processes. You have to work toward breaking down any barriers in communication—whether by getting to know a new teammate on a new project, working within your organization to dissolve silos, or trying to introduce a new workflow idea to your boss. A malleable process is a strong one.

The best place to start is with your project manager. It’s difficult to fit a new process into an ongoing project retroactively, so try to address this at the planning stage. If you’re about to begin a project, make the manager aware of your ideas and how the project plan could be shaped a little differently. It’s important for the project manager to understand the plan so that they can set the expectations with the client accordingly. It’s equally important for them to understand how the timeline will be affected, as it may depart from the typical flow your team is used to.

In large organizations, managers may need to run ideas past the managers of other departments. See if your next project can be a trial run for experimenting with a new process, and volunteer to head the initiative. Samantha Warren gave a fantastic presentation at An Event Apart on getting design ideas moved through an organization. If this doesn’t seem feasible, try building relationships with your counterparts yourself. See if they are open to trying new methods and working more closely together. If you get multiple people on board, it may be easier to convince the powers that be to try something new. Teams organically working well together are a powerful demonstration of just how effective collaboration can be.

Everybody benefits

Dive deeply into your passions while understanding the moving parts around you. Mastering your specialty is not only crucial for professional development and personal satisfaction, but it will also serve your team as you help to stretch that spectrum further. Projects benefit from experts who understand the whole while focusing on their strengths.

When we speak openly about shared end goals, our teamwork gets stronger. When we jump in and help out on cross-discipline deliverables, our teamwork gets stronger. Most importantly, when we combine our collective strengths and work together fluidly, it gives us the perfect recipe for an amazing project.

Remain true to your passions, but take the time to learn something about the skillsets of others to help you craft a unique team dynamic. The 80/20 guideline is a place to strive for—a place where we push our own skills and passions while rounding out our knowledge so that we can work better with our teammates. Being an 80/20 practitioner makes a stronger you and a stronger team.

Categories: Mobile learning

Pluralization for JavaScript

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

Seventy-one percent of today’s internet users don’t speak English as a first language, and that number keeps growing. But few people specialize in internationalization. As a result, most sites get it wrong—because things that seem straightforward are often anything but.

Take pluralization. Turning singular words into plurals within strings gets tricky quickly—even in English, where most plural words end with an s. For instance, I worked on a photo-sharing app that supported two languages, English and Chinese. It was easy to add an s to display “X like[s]” or “Y comment[s].” But what if we needed to pluralize “foot” or “inch” or “quiz”? Our simple solution became a broken hack.

And English is a relatively simple case. Many languages have more than two plural forms: Arabic, for example, has six, and many Slavic languages have more than three. In fact, at least 39 languages have more than two plural forms. Some languages only have one form, such as Chinese and Japanese, meaning that plural and singular nouns are the same.

How can we make sense of these complex pluralization issues—and solve them in our projects? In this article, I’ll show you some of the most common pluralization problems, and explain how to overcome them.

Problems with pluralization

Pluralization gets even more complex: each language also has its own rules for defining each plural form. A plural rule defines a plural form using a formula that includes a counter. A counter is the number of items you’re trying to pluralize. Say we’re working with “2 rabbits.” The number before the word “rabbits” is the counter. In this case, it has the value 2. Now, if we take the English language as an example, it has two plural forms: singular and plural. Therefore, our rules look like this:

  • If the counter has the integer value of 1, use the singular: “rabbit.”
  • If the counter has a value that is not equal to 1, use the plural: “rabbits.”

However, the same isn’t true in Polish, where the same word—“rabbit,” or “królik”—can take more than two forms:

  • If the counter has the integer value of 1, use “królik.”
  • If the counter has a value that ends in 2–4, excluding 12–14, use “królika.”
  • If the counter is not 1 and has a value that ends in either 0 or 1, or the counter ends in 5–9, or the counter ends in 12–14, use “królików.”
  • If the counter has any other value than the above, use “króliki.”

So much for “singular” and “plural.” For languages with three or more plural forms, we need more specific labels.

Different languages use different types of numbers

You may also want to display the counter along with the pluralized noun, such as, “You have 3 rabbits.” However, not all languages use the Arabic numbers you may be accustomed to—for example, Arabic uses Arabic Indic numbers, ٠١٢٣٤٥٦٧٨٩:

  • 0 books: ٠ كتاب
  • 1 book: كتاب
  • 3 books: ٣ كتب
  • 11 books: ١١ كتابًا
  • 100 books: ١٠٠ كتاب
Different languages or regions use different number formats

We also often aim to make large numbers more readable by adding separators, as when we render the number 1000 as “1,000” in English. But many languages and regions use different fractional and thousand separators. For example, German renders the number 1000 as “1.000.” Other languages don’t group numbers by thousands, but rather by tens of thousands.

Solution: ICU’s MessageFormat

Pluralization is a complex problem to solve—at least, if you want to handle all these edge cases. Recently, International Components for Unicode (ICU) did precisely that with MessageFormat. ICU’s MessageFormat is a markup language specifically tailored to localization. It allows you to define, in a declarative way, how nouns should be rendered in various plural forms. It sorts all the plural forms and rules for you, and formats numbers correctly. Unfortunately, many of you probably haven’t heard of MessageFormat yet, because it’s mostly used by people who work specifically with internationalization—known to insiders as i18n—and JavaScript has only recently evolved to handle it.

Let’s talk about how it works.

Using CLDR  for  plural forms

CLDR stands for Common Locale Data Repository, and it’s a repo that companies like Google, IBM, and Apple draw on to get information about number, date, and time formatting. CLDR also contains data on the plural forms and rules for many languages. It’s probably the largest locale data repository in the world, which makes it ideal as the basis for any internationalization JavaScript tool.

CLDR defines up to six different plural forms. Each form is assigned a name: zero, one, two, few, many, or other. Not all locales need every form; remember, English only has two: one and other. The name of each form is based on its corresponding plural rule. Here is a CLDR example for the Polish language—a slightly altered version of our earlier counter rules:

  • If the counter has the integer value of 1, use the plural form one.
  • If the counter has a value that ends in 2–4, excluding 12–14, use the plural form few.
  • If the counter is not 1 and has a value that ends in either 0 or 1, or the counter ends in 5–9, or the counter ends in 12–14, use the plural form many.
  • If the counter has any other value than the above, use the plural form other.

Instead of manually implementing CLDR plural forms, you can make use of tools and libraries. For example, I created L10ns, which compiles the code for you; Yahoo’s FormatJS has all the plural forms built in. The big benefits of these tools and libraries are that they scale well, as they abstract the plural-form handling. If you choose to hard-code these plural forms yourself, you will end up exhausting yourself and your teammates, because you’ll need to keep track of all the forms and rules, and define them over and over whenever and wherever you want to format a plural string.

MessageFormat

MessageFormat is a domain-specific language that uses CLDR, and is specifically tailored for localizing strings. You define markup inline. For example, we want to format the message “I have X rabbit[s]” using the right plural word for “rabbit”:

var message = 'I have {rabbits, plural, one{# rabbit} other{# rabbits}}';

As you can see, a plural format is defined inside curly brackets {}. It takes a counter, rabbits, as the first argument. The second argument defines which type of formatting. The third argument includes CLDR’s plural form (one, many). You need to define a sub-message inside the curly brackets that corresponds to each plural form. You can also pass in the symbol # to render the counter with the correct number format and numbering system, so it will solve the problems we identified earlier with the Arabic Indic numbering system and with number formatting.

Here we parse the message in the en-US locale and output different messages depending on which plural form the variable rabbits takes:

var message = 'I have {rabbits, plural, one{# rabbit} other{# rabbits}}.'; var messageFormat = new MessageFormat('en-US'); var output = messageFormat.parse(message); // Will output "I have 1 rabbit." console.log(output({ rabbits: 1 })); // Will output "I have 10 rabbits." console.log(output({ rabbits: 10 })); Benefits of inlining

As you can see in the preceding message, we defined a plural format inline. If it weren’t inlined, we might need to repeat the words “I have…” for all plural forms, instead of just typing them once. Imagine if you needed to use even more words, as in the following example:

{ one: 'My name is Emily and I got 1 like in my latest post.' other: 'My name is Emily and I got # likes in my latest post.' }

Without inlining, we’d need to repeat “My name is Emily and I got…in my latest post” every single time. That’s a lot of words.

In contrast, inlining in ICU’s MessageFormat simplifies things. Instead of repeating the phrase for every plural form, all we need to do is localize the word “like”:

var message = 'My name is Emily and I got {likes, plural, one{# like} other{# likes}} in my latest post';

Here we don’t need to repeat the words “My name is Emily and I got…in my latest post” for every plural form. Instead, we can simply localize the word “like.”

Benefits of nesting messages

MessageFormat’s nested nature also helps us by giving us endless possibilities to define a multitude of complex strings. Here we define a select format in a plural format to demonstrate how flexible MessageFormat is:

var message = '{likeRange, select,\ range1{I got no likes}\ range2{I got {likes, plural, one{# like} other{# likes}}}\ other{I got too many likes}\ }';

A select format matches a set of cases and, depending on which case it matches, it outputs the corresponding sub-message. And it is perfect to construct range-based messages. In the preceding example, we want to construct three kinds of messages for each like range. As you can see in range2, we defined a plural format to format the message “I got X like[s],” and then nested the plural format inside a select format. This example showcases a very complex formatting that very few syntaxes can achieve, demonstrating MessageFormat’s flexibility.

With the above format, here are the messages we can expect to get:

  • “I got no likes,” if likeRange is in range1.
  • “I got 1 like,” if likeRange is in range2 and the number of likes is 1.
  • “I got 10 likes,” if likeRange is in range2 and the number of likes is 10.
  • “I got too many likes,” if likeRange is in neither range1 nor range2.

These are very hard concepts to localize—even one of the most popular internationalization tools, gettext, can’t do this.

Storage and pre-compiled messages

However, instead of storing MessageFormat messages in a JavaScript variable, you might want to use some kind of storage format, such as multiple JSON files. This will allow you to pre-compile the messages to simple localization getters. If you don’t want to handle this alone, you might try L10ns, which handles storage and pre-compilation for you, as well as syncing translation keys between source and storage.

Do translators need to know MessageFormat?

You might think it would be too overwhelming for non-programming translators to know Messageformat and CLDR’s plural form. But in my experience, teaching them the basics of how the markup looks and what it does, and what CLDR’s plural forms are, takes just a few minutes and provides enough information for translators to do their job using MessageFormat. L10ns’ web interface also displays the example numbers for each CLDR plural form for easy reference.

Pluralization isn’t easy—but it’s worth it

Yes, pluralization has a lot of edge cases that aren’t easily solvable. But ICU’s MessageFormat has helped me tremendously in my work, giving me endless flexibility to translate plural strings. As we move to a more connected world, localizing applications to more languages and regions is a must-do. Knowledge about general localization problems and tools to solve them are must-haves. We need to localize apps because the world is more connected, but we can also localize apps to help make the world more connected.

Categories: Mobile learning

On Our Radar: Present Tense

A List Apart - Fri, 03/13/2015 - 17:39

It seems like we’re always anxiously awaiting the future, complications and all. Take the present moment: HTTP/2 is on its way, with intriguing changes for web development; web publishing has never been easier, but Medium’s latest direction is a mixed bag for authors; and our attention is increasingly in demand (and for sale). We’re living in the future, and we’ve got some mixed feelings about that.

Here’s what’s on our radar:

HTTP/2: On the horizon

HTTP/2 is on the horizon, a long-awaited upgrade to the web’s primary protocol. It promises better security and performance, but I’ve been curious about how it will impact development. Fortunately I came across two interesting posts that are a nice introduction to what HTTP/2 does and how it will affect the way we build websites:

Speaking of better performance, have you seen Tim Kadlec’s What Does My Site Cost? If you live in Angola, this page may have cost $0.32 (USD) to download—something you can bet we’ll be taking a hard look at.

Tim Murtaugh, technical director

Mediummm?

Last month, in a long Atlantic piece about the state of writing for the web, Robinson Meyer asked—for, like, the millionth time—“what is Medium, tho?” Is it publisher, or is it platform? Is it both?

Is it “just Tumblr for rich people”?

“All of the above” seems like the most accurate answer after yesterday’s announcement: custom domains for publications. Now, instead of going to medium-dot-com-slash-whatever to get the latest, you might head to cool-url-dot-biz, and find that it’s actually Medium now, too. You can already see this in action with Midcentury Modern. The magazine’s URL is midcenturymodernmag.com, but once you’re there, it’s Medium all the way down.

So what’s this mean for people like us—people who make websites and work with web content? Will publications flock to replace their custom sites with Medium? Probably not. But many organizations that otherwise might have cobbled together a Wordpress blog could easily end up launching a Medium publication instead, and I’m not sure how I feel about that. On the one hand, Medium’s invested heavily in design and extremely thoughtful typography. It’s great to see so much content written to be read (not to mention discussed and shared). On the other, as both publisher and platform—both the magazine and the paper it’s printed on at the same time—Medium controls everything about how the content published with it is presented, regardless of the URL it ends up on: layout, type, functionality. Does that leave enough space for authors and organizations?

Sara Wachter-Boettcher, editor-in-chief

We’re living in a future predicted 60 years ago

In my youth, old science fiction short story compilations were a mainstay of my summer reading. One story I vividly remember is Frederik Pohl’s “The Midas Plague,” set in a world so rich in stuff that the poor are obliged to consume constantly, while the wealthy can afford emptiness and silence.

I was reminded of that world as I read Matthew Crawford’s “The Cost of Paying Attention.” It becomes even more real in light of Daniel Levitin’s explanation that the brain runs on a daily ration of fuel that is depleted with every target of focus and every decision—and it makes no difference whether they’re important or insignificant.

Attention is a limited and very valuable resource that we have to protect when it’s our own, and respect when it’s our neighbor’s.

Rose Weisburd, columns editor

A gif about: uncertainty I am having second thoughts. What about you?

What stories are drawing your attention? Got any posts, pictures, tools, or code you want to share? (We love sharing!) Tweet us what’s on your radar—and what should be on ours.

Categories: Mobile learning

This week's sponsor: SkillFeed

A List Apart - Thu, 03/12/2015 - 14:23

Thanks to SkillFeed for sponsoring A List Apart this week. Sharpen your skills, or learn something new, with free access to their tutorials and courses.

Categories: Mobile learning

Nishant Kothary on the Human Web: There Is No Data vs. Intuition

A List Apart - Thu, 03/12/2015 - 12:30

Few things have widened the chasm between data and intuition as much as Marissa Mayer’s infamous matter of the 41 Shades of Blue a few years ago.

For those of you who live under a rock, let me catch you up.

Back when there were just 41 shades

Back in the golden age when Google wasn’t evil, they used two different shades of blue for the hyperlinks in Search and Gmail ads. The decision was made to determine the one true blue, and it was ultimately Mayer’s to make. Her intuition to split the difference between two final contenders left her uneasy. So naturally, she devised a most elaborate A/B test to determine the best blue among 41 different blues.

And then everyone wrote about it. Bowman. Clark. Fast Company. CNET. Gawker. Gigaom. The New York Times. Even I piled on in my own little way. And the verdict that came out at the end of the human centipede was a collective, “Eww, she did what?!”

Taking a page from Kim Kardashian, who recently owned her own narcissism in this (really, quite effective) T-Mobile commercial, Google’s design team themselves embraced and commemorated their data-driven philosophy late last year in the Googliest of ways. In 41 successive tweets they tweeted—you guessed it—those infamous 41 shades of blue. And the 42nd tweet, in classic Google form, a puzzle:

Those first 41 tweets? A salute to our past, and a look toward our future. #41shades #4285F4

— Google Design (@GoogleDesign) October 23, 2014

We have Will Kirkby to thank for bit-shifting his heart to the solution, an inspirational quote: “we seek to synthesize classic principles of good design with the innovation and possibility of technology and science…”

*Slow clap*

All made up but nowhere to go

Judging by the fun and games, it seems like we’ve all made up. As much as I’d love to applaud us all for putting our demons to rest and working it out, it’s hard to ignore the underlying cause of this years-long kerfuffle: the data vs. intuition debate (if I can even call something this dogmatic a debate).

The debacle quietly renewed the old, tired, artificial, and patently false, division between data and intuition. And from where I stand, divided they remain.

Back to square one. Designers vs. Engineers. Emotions vs. Logic. Intuition vs. Data.

So, before it gets too late, let me just get this on the record: if you find yourself arguing at dinner parties that intuition has no place in the decision-making process (have you noticed that nobody ever seems to do the opposite?), well, then first off: stop lying because nobody invites you to dinner parties. But more importantly, I want to do you a solid and tell you that you may be the accidental modern jackass. Because you’re plain wrong.

And there’s a mound of data that supports that.

Data vs. and intuition

If you’re curious about the data supporting the intelligence of the gut, you can start with Malcolm Gladwell’s Blink. But I recommend it with acute awareness of the polarizing effect of referencing Gladwell as a case for science. So before you cut your losses and head back to your timeline, my second recommendation is the source of much of the great research out there on intuition: Gerd Gigerenzer’s very readable treatise on the topic, Gut Feelings: The Intelligence of the Unconscious. Its extensive bibliography will satiate those of you who want to dive into the p-values of the randomized control trials, while it doubles as a jumping-off point for the topic as a whole.

You don’t have to go very far into the research before you realize something you’ve always known in your gut: that your gut is frikkin’ smart. From catching a flyball to becoming a world-class athlete, from picking winning stocks to dreaming up entirely new markets, the intelligence of the gut is awesome in the truest sense of the word: it draws awe.

But, here’s the thing: data is just as awesome. 

Data has a way of turning a suspicion into a verifiable fact. It has the ability to replace dogma with truth. To provide answers to vexing problems simply with math. As Christian Rudder writes in Dataclysm: Who We Are, “It’s like looking at Earth from space; you lose the detail, but you get to see something familiar in a totally new way.”

Some of you already know where I’m going with all of this: we’re punching ourselves in the, well, gut, by continuing to pit intuition against data. It’s not one or the other. It never has been, and as much as we try to sell the narrative, it never will be. They are both mandatory in sound decision-making (there’s a good book on that, too, by the way).

The fact is that there is no data vs. intuition.

Finally

Ironically, Mayer’s rationale for her design decision—her execution (or its reporting and our understandable reactions) notwithstanding—was actually pretty sound: “Every design starts with an instinct: It should look like this, or it should look like that. You can actually test it with data. The humbling thing about that is sometimes the data proves you wrong. So for every change I propose, you know, three out of four, four out of five the data will support the change.”

And if you’re to believe the press, it was worth $200m a year. But who knows.

Regardless, here’s a thought experiment: can you see an alternate universe where a Jobs-esque genius gets a standing ovation for employing Mayer’s line of reasoning?

Let your gut noodle on that for a bit.

 

Categories: Mobile learning

Brevity vs. Clarity

A List Apart - Fri, 03/06/2015 - 14:45

A few months ago, my good friend, Olivier Lacan, tweeted:

Why do CSS author seem to agree that “btn” stands for button while “large” doesn’t need “lrg”? Stop abbreviating because others do it.

— Olivier Lacan (@olivierlacan) September 6, 2014

He rightly points out that a lot of commonly-accepted abbreviations exist only because a critical mass of people use them. We understand what “btn” means because we’ve seen it before, not because it’s a clear shortening of “button.”

Is the loss of clarity outweighed by the benefits of a shorter class name? In an era where most text editors provide autocompletion, three letters isn’t a huge difference from an authoring perspective.

Inevitably, someone else will come along someday and work with the code we write. Even if you work by yourself, future you will be a different person because of the work you’ve done and the experiences you’ve had between the times you focus on a project. Clarity is invaluable when others (or our future selves) come in to work on something—we don’t have to struggle to understand what is happening, we can get work done more efficiently, and the overall process will be much smoother.

On the technical side, brevity certainly has its place. The savings made by using a fewer letters each time a name is written can add up if your codebase is large enough. Better yet, minification and compression of CSS and JavaScript source files can save precious kilobytes and shorten page load times noticeably. There’s really no shortage of micro-optimizations you can find out there, all in the name of brevity and speed.

There are clearly good reasons for both approaches, so like most things in our work, it all comes down to how you decide what’s right for you and your situation. Is there a tangible, data-proven benefit of brevity? If not, be descriptive, expressive, and clear.

Hal Abelson and Gerald Jay Sussman said it best in their MIT Structure and Interpretation of Computer Programs course:

Thus, programs must be written for people to read, and only incidentally for machines to execute.

I let that guide me, but the lines between what’s for humans and computers can get blurry sometimes—JavaScript and CSS files are for both humans and machines, so it’s best to find a way to play to both sides’ advantages. Minification and compression are good tools here: clear source code for development, minified and compressed files for production.

No matter what, avoid abbreviating for abbreviation’s sake. The benefits of clear, readable code are almost always greater than typing fewer characters. And if brevity is applied thoughtfully in technical situations, you’ll use resources more efficiently, and that will make everyone happy.

 

Categories: Mobile learning

What do we need typefaces to be?

A List Apart - Thu, 03/05/2015 - 22:08
What do we need typefaces to be? To do for us? Do we need a larger variety of widths – maybe more subtle width variations – to help us cope with viewport dimensions? Or more optical styles, to help us deal with reading distance? Do we want more typefaces with different thicknesses (grades), for different resolutions? Type designers want to know. Yours truly, speaking about Universal Typography at AEA San Diego

Yesterday, Adobe Type announced a new effort called Adobe Type Concepts. These are promising font seedlings, and we have all been invited into the design process to help them grow. Type designers do indeed want to know what we, people who make websites, want.

Adobe has employed type designers for more than 25 years. Apple’s brand typeface is a customized version of Myriad. Robert Bringhurst chose Minion as the text face for The Elements of Typographic Style. Many movies make use of Trajan, the eternal letter. And, Adobe Type’s recent open source typefaces have proven very popular. The process of making Adobe-quality typefaces like these takes years.

Vortice Concept, by Miguel Sousa

Concept fonts are an incredible opportunity because we, people who make websites, get to witness and participate in the type design process. Adobe Type is listening to us as they turn Concept fonts like Vortice into full-fledged typefaces — typefaces that can, with our help, reflect the dynamic needs of the web.

Please take Vortice for a spin. Leave feedback on its project page, on the blog post announcement, or with @AdobeType. It is amazing to have a direct connection with such a historic type foundry, and to know that they recognize the open-endedness of the web.

When type designers succeed, so do we. Trent Walton, Jiro, Sushi & Web Type
Categories: Mobile learning

This week's sponsor: UserZoom

A List Apart - Thu, 03/05/2015 - 14:18

Thanks to UserZoom for sponsoring A List Apart this week! Check out their guide to integrating user experience and usability testing in an agile design process.

Categories: Mobile learning

Rachel Andrew on the Business of Web Dev: Looking Outside

A List Apart - Thu, 03/05/2015 - 13:30

Running a business with your spouse has advantages. A year ago we decided—after asking Twitter where was nice to live—to move from Maidenhead to Bristol. We were able to relocate home and business easily because our work and life together is one thing. We can head out for a walk or a run together and chat through a possible new feature for Perch or a business decision that needs making. Our life and business goals are one and the same.

My husband Drew McLellan and I are each a 50 percent shareholder in the business, while my college-aged daughter works for us part time. Other roles are fulfilled by contractors and freelancers. Major business decisions, from product features to financial issues, are made by the two of us.

We do have defined roles. I started the company, so a lot of the business of doing business comes down to me. I also enjoy the activity of running a business, and have a good head for accounting and legal issues. Drew is lead developer on Perch, and the direction of the product and codebase is his. We discuss most decisions, but there are distinct areas of the business that we each take the lead on.

However, when decisions need to be made that one partner is unhappy with, the overspill into non-work life can be difficult. How do we support each other as husband and wife while being able to argue the pros and cons as business owners? Where most people can leave work and head home to get outside input from their partner, couples in business can find themselves without that outlet.

Even when things are going well, there is a danger of becoming insular. On many issues, Drew and I come to a shared conclusion quickly. Is that because we are right or just because we read the same things, have the same experiences? These are difficult questions to answer.

Our small part of the web industry can be a navel-gazing place at times. Just watch how the same tweets circulate, the same products are mentioned, by the same small group of people. Asking advice from my friends in the industry can be very similar to asking advice from my partner. They know me and what I do too well, and are probably being influenced by the same books, blog posts, and speakers as I am.

Sometimes it takes an outsider to point out the mistakes you are making, and to open up conversations and ask questions that you might never ask yourself.

Getting some “business therapy”

Drew and I really enjoy watching business reality shows on TV—especially the sort of thing where an experienced businessperson goes into a failing business to help them out. A show airing in the UK at the moment has hotelier Alex Polizzi performing this role in family businesses. We cringe as we see the TV businesses making seemingly obvious mistakes. We sometimes wonder how much our own perspective prevents us seeing our own errors and the opportunities we miss out on.

Having an outsider look at your business can be incredibly helpful. We recently applied for, and were accepted into, the UK Business Growth Service’s Growth Accelerator scheme. This comes with several benefits, but the most interesting to us is the chance to work with a business advisor. When I first heard about the scheme, I had visions of being paired with an ex-bank-manager type, someone from a very traditional business. I imagined I’d spend more time explaining how our business worked than getting any real advice. That hasn’t been the case. Our advisor, Matt Spry, has enough technical background to understand what it is we do, but enough distance and wider business experience to be able to ask us questions we’d not ask ourselves.

We’ve been led through exercises that we know are a good idea but that seem a bit odd to do on our own, especially as a couple in business. Last week we covered a table in a local café in sticky notes to work out which aspects of our product are most important to different groups of customers. Every time we meet with Matt, it sparks conversations we might not have had with each other. It does sometimes feel a bit like “business therapy.” Even though Drew and I tend not to have too many conflicting ideas for the business, having a third party pose questions that are very much in one of our areas of responsibility is certainly helpful.

We’re still in the middle of this process with the Growth Accelerator scheme. It is too early to judge whether this input will increase the success and growth of the business. We have already found, however, that voicing concerns and considering a different viewpoint has started to make us confident to try changes we might have avoided before.

Finding your own outside help

We’re involved in a formal scheme, but there are other ways in which you could get input for your own business, whether you work alone or run a family business of some sort. Many of my peers are part of mastermind groups, groups of three or four people who meet regularly to offer input into the businesses of each member of the group. Episode 167 of Startups for the Rest of Us talks about how to set up and run such a group. Another method would be to try to find a business mentor. In that case, I’d advise looking a little outside of your direct field in order to gain a true outside perspective. Close friends are unlikely to ask the hard questions, and may just confirm the things you think you already know.

It’s so tempting to think we know it all. It’s so easy to become inward looking, especially when working alone, or with a partner or close friend. I’ve come to realize just how valuable an outside perspective can be. I’d encourage every business to look for ways to get that kind of input.

Categories: Mobile learning

Literacy, gender and mobiles

Mlearnopedia - Thu, 03/05/2015 - 08:31
Brief for the panel: Due to a history of educational inequity, many more women than men are illiterate: globally, 64 per cent of illiterate people are women. Motherhood and assumed family obligations can further prevent women from building literacy skills in formal education settings. Below are my speaking notes. Increase visibility.

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