lundi 31 août 2015

Google AdWords Adds Structured Snippet Extensions

Google is to roll out, in the coming weeks, structured snippet extensions to its dynamic structured snippets for AdWords.

via planetweb

dimanche 30 août 2015

Google Challenges the European Commission's Statement of Objections

"We believe that the SO's preliminary conclusions are wrong as a matter of fact, law, and economics."

via planetweb

vendredi 28 août 2015

Chrome will start automatically pausing less important Flash content

Could this be the beginning of the end of Flash-based ads?

via planetweb

Google Launches Redesigned In-App Interstitials

Google is giving in-app interstitials a makeover with a new design.

via planetweb

jeudi 27 août 2015

Facebook Testing a Virtual Assistant, "M"

Everyone will soon have a virtual assistant at this rate!

via planetweb

mercredi 26 août 2015

Bing Adds More Control For Bing Maps Tile Layers

Bing has added more control over Maps tile layers.

via planetweb

This week's sponsor: Craft

Time to look for a new CMS? Our sponsor Craft keeps the editing experience simple, flexible, and responsive.



via planetweb

Firefox to Adopt Chrome Add-Ons Format

Controversial topic as Firefox changes to adopt Chrome-like add-ons.

via planetweb

Multimodal Perception: When Multitasking Works

Word on the street is that multitasking is impossible. The negative press may have started with HCI pioneer Clifford Nass, who published studies showing that people who identify as multitaskers are worse at context switching, worse at filtering out extraneous information, worse at remembering things over the short term, and have worse emotional development than unitaskers.

With so much critical attention given to multitasking, it’s easy to forget that there are things our brains can do simultaneously. We’re quite good at multimodal communication: communication that engages multiple senses, such as visual-tactile or audio-visual. Understanding how we process mixed input can influence the design of multimedia presentations, tutorials, and games.

When I began researching multimodal communication, I discovered a field brimming with theories. The discipline is still too new for much standardization to have evolved, but many studies of multimodality begin with Wickens’s multiple resource theory (MRT). And it’s that theory that will serve as a launch point for bringing multimodality into our work.

Wickens’s multiple resource theory

Luckily, Wickens saved us some heavy lifting by writing a paper summarizing the decades of research (PDF) he spent developing MRT. Its philosophical roots, he explains, are in the 1940s through 1960s, when psychologists theorized that time is a bottleneck; according to this view, people can’t process two things simultaneously. But, Wickens explains, such theories don’t hold up when considering “mindless” tasks, like walking or humming, that occupy all of a person’s time but nevertheless leave the person free to think about other things.

Several works from the late 1960s and early 1970s redefine the bottleneck theory, proposing that what is limited is, in fact, cognitive processing power. Following this train of thought, humans are like computers with a CPU that can only deal with a finite amount of information at once. This is the “resource” part of MRT: the limitation of cognitive resources to deal with incoming streams of information. (MRT thus gives credence to the “mobile first” approach; it’s often best to present only key information up front because of people’s limited processing power.)

The “multiple” part of the theory deals with how processing is shared between somewhat separate cognitive resources. I say somewhat separate because even for tasks using seemingly separate resources, there is still a cost of executive control over the concurrent tasks. This is again similar to computer multiprocessing, where running a program on two processors is not twice as efficient as running it on one, because some processing capacity must be allocated to dividing the work and combining the results.

To date, Wickens and others have examined four cognitive resource divisions.

Processing stage

Perception and cognition share a structure separate from the structure used for responding. Someone can listen while formulating a response, but cannot listen very well while thinking very hard. Thus, time-based presentations need ample pauses to let listeners process the message. Video players should have prominent pause buttons; content should be structured to include breaks after key parts of a message.

Visual channel

Focal and ambient visual signals do not drain the same pool of cognitive resources. This difference may result from ambient vision seemingly requiring no processing at all. Timed puzzle games such as Tetris use flashing in peripheral vision to let people know that their previous action was successful—the row was cleared!—even while they’re focusing on the next piece falling.

Processing code

Spatial and verbal processing codes use resources based in separate hemispheres of the brain. This may account for the popularity of grid-based word games, which use both pools of resources simultaneously.

Perceptual modes

It’s easier to process two simultaneous streams of information if they are presented in two different modes—one visual and one auditory, for example. Wickens notes that this relative ease may result from the difficulties of scanning (between two visual stimuli) and masking (of one auditory stimulus by another) rather than from us actually having separate mental structures. Tower defense games are faster paced (and presumably more engaging) when accompanied by an audio component; players can look forward to the next wave of attackers while listening for warning signals near their tower base. Perceptual modes is the cognitive division most applicable to designing multimedia, so it’s the one we’ll look at further.

A million and one other theories

Now that we’ve covered Wickens’s multiple resource theory, let’s look at some of the other theories vying for dominance to explain how people understand multimodal information.

The modality effect (PDF) focuses on the mode (visual, auditory, or tactile) of incoming information and states that we process incoming information in different modes using separate sensory systems. Information is not only perceived in different modes, but is also stored separately; the contiguity effect states that the simultaneous presentation of information in multiple modes supports learning by helping to construct connections between the modes’ different storage areas. An educational technology video, for instance, will be more effective if it includes an audio track to reinforce the visual information.

This effect corresponds with the integration step of Richard Mayer’s generative theory of multimedia learning (PDF), which states that we learn by selecting relevant information, organizing it, and then integrating it. Mayer’s theory in turn depends upon other theories. (If you’re hungry for more background, you can explore Baddeley’s theory of working memory, Sweller’s cognitive load theory, Paivo’s dual-coding theory, and Penney’s separate stream hypothesis.) Dizzy yet? I remember saying something about how this field has too many theories…

What all these theories point to is that people generally understand better, remember better, and suffer less cognitive strain if information is presented in multiple perceptual modes simultaneously. The theories provide academic support for incorporating video into your content, for example, rather than providing only text or text with supporting images (says, ahem, the guy writing only text).

Visual-tactile vs. visual-auditory communication

Theories are all well and good, but application is even better. You may well be wondering how to put the research on multimodal communication to use. The key is to recognize that certain combinations of modes are better suited to some tasks than to others.

Visual-tactile

Use visual-tactile presentation to support quick responses. It will:

  • reduce reaction time
  • increase performance (measured by completion time)
  • capture attention effectively (for an alert or notification)
  • support physical navigation (by vibrating more when you near a target, for example)

Visual-auditory

Use visual-auditory presentation to prevent errors and support communication. “Wait, visual-auditory?” you may be thinking. “I don’t want to annoy my users with sound!” It’s worth noting, though, that one of the studies (PDF) found that as long as sounds are useful, they are not perceived as annoying. Visual-auditory presentation will:

Mode combination

You might also select a combination of modes depending on how busy your users are:

  • Visual-tactile presentation is more effective with a high workload or when multitasking.
  • Visual-auditory presentation is more effective with a single task and with a normal workload.

Multimodal tension

A multimodal tug-of-war goes on between the split-attention effect and the redundancy effect. Understanding these effects can help us walk the line between baffling novices with split attention and boring experts with redundancy:

  • The split-attention effect states that sequential presentation in multiple modes is bad for memory, while simultaneous presentation is good. Simultaneity helps memorization because it is necessary to encode information in two modes simultaneously in order to store cross-references between the two in memory.
  • In contrast, presenting redundant information through multiple channels simultaneously can hinder learning by increasing cognitive load without increasing the amount of information presented. Ever try reading a long quote on a slide while a presenter reads the same thing aloud? The two streams of information undermine each other because of the redundancy effect.

Which effect occurs is partially determined by whether users are novices or experts (PDF). Information that is necessary to a novice (suggesting that it should be presented simultaneously to avoid a split-attention effect) could appear redundant to an expert (suggesting that it should be removed to avoid a redundancy effect).

Additionally, modality effects appear only when limiting visual presentation time. When people are allowed to set their own time (examining visual information after the end of the auditory presentation), studied differences disappear. It is thus particularly important to add a secondary modality to your presentation if your users are likely to be in a hurry.

Go forth, multiprocessing human, and prosper

So the next time you hear someone talking about how multitasking is impossible, pause. Consider how multitasking is defined. Consider how multiprocessing may be defined separately. And recognize that sometimes we can make something simpler to learn, understand, or notice by making it more complex to perceive. Sometimes the key to simplifying presentation isn’t to remove information—it’s to add more.

And occasionally, some things are better done one after another. The time has come for you to move on to the next processing stage. Now that you’ve finished reading this article, you have the mental resources to think about it.



via planetweb

samedi 22 août 2015

Defining Negative SEO, From a Legal Perspective

WebmasterWorld Members debate the true definition of negative SEO, from a legal standpoint.

via planetweb

jeudi 20 août 2015

Adobe Flash Ads Kicked Off Amazon

Amazon will no longer accept Adobe Flash ads from September 1, 2015.

via planetweb

New Bing Knowledge and Action Graph API for Developers

Bing App for Android now updated with snapshots from the knowledge and action graph available on tap.

via planetweb

mercredi 19 août 2015

This week's sponsor: Proposify

Save time writing and designing your next proposal with help from our sponsor, Proposify.



via planetweb

IE V7 to V11 Critical Vulnerability - Out of Schedule Patch To Follow

Microsoft is to release an out-of-schedule patch for this critical vulnerability for IE. MS Edge browser is unaffected.

via planetweb

samedi 15 août 2015

Is Web Development for Grown Ups?

WebmasterWorld Members debate whether age is a barrier in coding, and will they still be coding when they get to 40, 50, or 60 years old.

via planetweb

vendredi 14 août 2015

Building to Learn

I’ve spent my fair share of the last 10 years in the web world learning new things. We all have; it’s the one constant in this industry: things will change and you will need to change with them.

And for people just starting out on the web, building and learning is pretty much continual. This summer, as a friend learns to build things on the web for the first time, I’ve thought more about how I learned, how I got started in this webbish world in which I find myself day in and day out.

If you’re just getting started on the web the biggest piece of advice I have for you is: build something that interests you. That may not sound that radical, but it’s truly one of the best ways I’ve found to learn something new, whether that’s here on the web or elsewhere in life. Many online code courses have you building something they’ve chosen, but if you don’t care about building their to-do list or whatever, you aren’t going to be as excited about the project. If you aren’t excited about it, you aren’t going to learn as much.

When I was first learning HTML, CSS, and ColdFusion (yes, I learned ColdFusion as my first dynamic language to interact with a database), I made a small site about art. I went back to school to learn about the web because it was more marketable than the art degree I got in college, but art was something I was still very interested in and familiar with—plus, I had resources sitting around in my personal library for data and information. I remembered a small book on artwork through history I had on my shelf and used it as the basis for a small site. It was perfect because it gave me the database fields easily (such as the title, artist, date, and genre). The structure of the book made some of those decisions for me, so I could focus on the code. It was thrilling when I was done, when I could click around a site and pull up various art works. It wasn’t perfect, but I learned a lot about how to pull information from a database that’s still relevant in my work today.

In addition to creating something that’s interesting to you, many folks suggest making something you would actually use in your day-to-day life. One thing I’ve seen is a meal planning application that someone made for themself and was able to use with their partner regularly. Maybe you’re interested in history and want to link publicly available photos to places in your city. What you make isn’t as important as the fact that you’re excited to make it. You want the finished product, so hopefully you’ll persevere through the tough parts.

Of course, having to do something is also a great motivator for learning how to get it done. When I was on a project and we had to get a password meter working with JavaScript, a colleague coached me through it and I learned. When I was passed a new design to lay out and it seemed like flexbox would be a great solution, I learned flexbox as I got the site working in the browser.

I’ve found when I start doing an online tutorial, if I’m not interested in what they’re having me build, I don’t learn as much. It’s not that I don’t understand what’s going on, but the concepts don’t stick with me. When I need to figure something out on the job or I’m building something that I want to use in my own life, though, I learn so much more. And when I need to use those same coding concepts that I learned to make that password meter in JavaScript, they come back to me more easily.

I’ve already written about how learning new things in our industry can be overwhelming with all the options out there and all the change that is constantly happening. But when you slow down and focus on something you find useful or something you need to know how to do, you flip the equation. Instead of trying to get through a tutorial or lesson, you’re making something you want, which keeps you motivated as you figure out how to get there. When you need to remember those concepts down the road, it’s so much easier to retrace how you built a project you’re excited about and proud of instead of a cookie-cutter tutorial you can’t quite remember.



via planetweb

jeudi 13 août 2015

Members Discuss Windows 10 Upgrade Issues

Members relating issues with new Windows 10 installs which continues to download, including on bandwidth restricted mobile services. Some issues still not addressed.

via planetweb

Rachel Andrew on the Business of Web Dev: Creating Process to Free up Time for Creativity

In The E-Myth Revisited, Michael Gerber encourages entrepreneurs to develop business systems, going as far as to suggest we should build our businesses as if we intended to create franchise operations. This idea of process and systems is a popular one-taken to an extreme by people such as Tim Ferris in The Four Hour Workweek. This complete systemization of business activities is rightly pushed back against by many people working in creative fields. The act of creating something new can’t be written out as a series of steps. The individual creator, the artist, is important. That role can’t be just anyone who is able to follow the instructions.

On a recent Startups for the Rest of Us podcast, the discussion was about people versus process. This suggested that you can either value people and their creativity, or you can develop a very process-driven business, where you can slot in any person to step through the tasks. I think there is a middle ground. Documenting procedures for tasks that benefit from a structured approach can leave more flexibility when tackling creative work.

What do we mean by process?

When we turn a task into a process or system, we identify all of the steps we go through to perform that task and make that a checklist. My process for reconciling transactions in Xero is:

  1. Look at the incoming bank transaction.
  2. Find the receipt or invoice for this transaction.
  3. Add the details from the receipt into Xero.
  4. Check that, if tax has been applied, I have entered the correct rate, and that it is detailed on the receipt.
  5. Upload a PDF version of the receipt to Xero and also store it in Dropbox named with a reference for the account name it came out of.
  6. Mark the transaction as reconciled.

This is not creative work, it’s a rote task. Following this practice around bank reconciliations has benefits:

  • I know that any reconciled transaction will have an associated invoice or receipt. If I need to produce that proof, I know where they are stored, as the process prevents mistakes caused by me forgetting what to do here.
  • It removes friction. I don’t need to expend any energy remembering what to do.
  • It makes it easy for me to outsource this task. If I’m bringing on board a new bookkeeper, I can explain this process and be able to see that it is being followed.

By creating a process, I can get this task out of my head. Reconciling accounts isn’t my favorite job, but when I need to do it I can grab a coffee and step through each item on the checklist without spending any time thinking through it. I add these boring but important tasks to a special Context in OmniFocus that contains tasks to work through on those days where I’m having a hard job focusing for some reason.

This is a fairly simple example, but the same method can be applied to more complex tasks in your business. For example, which steps need to be followed when you take on a project with a brand new client? You might include:

  • Creating a file (from a template) for their basic information, such as who to invoice, agreed terms and so on.
  • Sending them a contract to sign.
  • Saving the signed contract.
  • Sending an initial invoice.
  • Ensuring that payment terms have been agreed.
  • Setting them up on a collaboration tool, such as Basecamp or Slack.
  • Safely storing any login details you need for their hosting.

Again, this is not creative work. How you go about it might differ from client to client. You might go through this list in person with one client and via email with another. Either way, the checklist ensures that you have agreed payment terms. It ensures you have a contract, and that you have received any assets they need to provide you up front (which could well save you time when you need something and the client is out of the office).

Checklists and process can also help make jobs you find difficult far easier. Perhaps you dislike talking about money with new clients. Sending that email containing the estimate for a job can become an all-day procrastination affair! The checklist can take your mind off the potential result of the interaction and help you focus on performing the steps to get to that point.

Leaving your brain free for creativity

The power of process is that it can free up time and energy to do things that can never be reduced to a checklist. To-do lists stop your brain endlessly having to remember what you need to do today, and process documentation can work in the same way. You no longer need to remember what must happen to complete a certain task. Though often seen as a way to outsource parts of your business, putting process in place can also benefit the one- or two-person business.

If you do go on to expand your business, having good processes can make it far easier to bring in permanent or temporary help. Those tried and tested checklists can be given to someone who can perform the rote tasks, leaving you to do the more interesting creative work.

Most importantly, by not expending effort on the mundane you can leave more time free for the work you love to do—the work that can only be done by you. You can then feel free to put aside all thoughts of checklists and to-do lists and work in exactly the way you know enables your best accomplishments.



via planetweb

Amazon Retiring Product Ads From October 31

Amazon is to close its PPC product ads program on 31 October.

via planetweb

mercredi 12 août 2015

Report: Ad Blocking is Worth $22 Billion in Lost Revenue

"We find that not only has ad blocking continued its fast growth on desktop, but it has also leaped onto mobile in Asia, and will soon go mobile in the West with the upcoming launch of content blocking on iOS."

via planetweb

This week's sponsor: Bushel

Managing MacBooks and iPhones for your team? Our sponsor Bushel is here to help, so you can focus on work.



via planetweb

Sharing Our Work: Testing and Feedback in Design

When I was a younger, less experienced designer, I was uncomfortable showing work that wasn’t “done.” I thought that design was something I should show only in its glorious, final state.

Many designers and design processes suffer from the same isolation problem: we don’t show our work to our users until the very end—when they’re stuck with it. We treat research as a box to check off, rather than an asset to use as a design evolves. We rely on personal opinions to make decisions instead of validating them with the people using the product.

However, the more we share our work in progress, using a variety of testing methods at every stage of design, the more input we can get from the people the design is for. Multiple research methods ensure that we receive diverse feedback; and more diverse feedback helps our products better meet our users’ needs.

Learning to share

When I first came to Etsy, I was surprised to learn how much their design process focuses on iteration and testing. Designers show Etsy’s buyers and sellers early versions of new designs to get direct feedback.

This doesn’t just happen once, either—research is integrated throughout the entire design process, from small conceptual tests to working prototypes to fully functioning features. At each point in the design process, we ask specific questions to help us move forward to the next phase of work.

To answer these questions, we use different research and testing methods, tailored to the type of feedback we’re looking for. Each type of research has strengths and weaknesses. If we limited ourselves to one type of research, like usability testing, we wouldn’t catch everything. Gaps in the feedback would leave us to build something that didn’t totally align with what our users need.

Here is how we use research at Etsy at each point in the design process to solicit different types of feedback (and the surprises we encounter along the way!).

Definition

At the beginning of a project, we define what we’re going to build. To formulate a project goal, we start by looking at high-level business goals, research from past user testing, and data on current Etsy usage. The direction we pick in this phase dictates what the next few months of work will look like, so user validation is particularly important here.

To help choose our path, we create low-fidelity mockups and do concept testing with Etsy users who fit the target audience for the project. Rather than invest a lot of engineering time up front on building something we might not use, we often test clickable prototypes, which, while clunky, are cheap to create and involve zero engineering time. They’re mockups of an unbuilt interface, which also means we’re able to throw in blue sky features. Focusing on the best-case scenario of the feature lets us test whether sellers grasp the concept—realism and constraints can come later.

My team at Etsy, Shop Management, recently tested concepts for a promotional tool for sellers. We had a rough idea of what we wanted to build, but it was important to see if sellers understood the feature and its benefits before we went too far. We recruited sellers to remotely walk through our prototype, asking them:

  • “What’s the purpose of this screen?”
  • “Tell me about what you just did there.”
  • “What’s the value of this tool?”
  • “How would you use a tool like this for your shop?”
  • “How would you describe this tool to a friend?”

Even though the format of these sessions is similar to how usability testing is conducted, we’re not focused on usability feedback at this early stage; we’re more concerned with solidifying a direction. There might be gaping holes or implausible scenarios; in one version of our clickable prototype, I forgot to account for the iOS keyboard! But mixing up details like that is okay when the questions we’re asking are broad. Instead of focusing on the interface, we’re asking participants about the idea. Validating our direction as early as possible sets us up for success down the road.

Design

Once the concept has been validated, we dive into designing the new feature. Design constraints come into play, and we’re now tasked with solving some of the details that we punted on in earlier conceptual versions. As more constraints are applied and we get deeper into uncovering the specifics of what we’re creating, the research becomes more focused on the interface itself. This is where usability testing becomes our best friend.

Last year, the Shop Management team redesigned the core of Etsy’s seller tools, the Listings Manager. The redesign was much needed; the interface was showing its age, and so was the technology behind it. Many useful new features had been added to the Listings Manager over the years, but they were added as their own pages instead of being integrated into existing workflows. Nothing was optimized for mobile, despite increased traffic to Etsy from mobile devices. We needed to rearchitect the Listings Manager with sellers’ workflows and technology best practices in mind.

Redesigning such an integral part of a seller’s toolset was going to be tricky, though. Sellers are very sensitive to change because these tools are what they use every single day to run their businesses. So we conducted usability testing every two weeks to make sure our design decisions matched the way sellers wanted to work. And we used task-oriented questions during these sessions, like asking sellers to:

  • perform an action that existed in the old design, like editing a listing
  • find a familiar feature, like “quick edit,” in a new location
  • go through a common flow, like finding a listing that had expired and renewing it
  • use new design paradigms, like a gear dropdown for performing actions

We tried a few clever ways of redesigning the Listings Manager interface; for example, we added a sidebar for editing listings, so sellers wouldn’t have to go to an entirely new page. But the sidebar totally bombed—it required way too much scrolling and wasn’t as useful as we anticipated. It was painful for us to watch sellers struggle to use our prototype. Thanks to usability testing, we immediately ditched the sidebar and moved on to a more practical interface.

Development

After weeks of iteration, we have a solidified design that works end to end. The product has bugs and missing features, needs a lot of polish, and is months away from launch—but this is when we want Etsy users to start kicking the tires and using it as a part of their normal workflows.

Usability testing is great for feedback on specific tasks and first impressions, but because it’s a simulated environment, it can’t provide the answer to every question. We might still be trying to validate whether we successfully hit the original goals we set for our project, and for that we need the feedback of people who use the product regularly.

To catch these types of issues and to vet new features on Etsy, we created beta tester groups to opt-in specific buyers and sellers to early versions of our features. We call these “prototype groups,” and each one has a forum in which members can post feedback and talk to one another and to our product teams. The scale of prototype groups can range anywhere from a few dozen people to thousands; our largest prototype group to date has been 10,000 Etsy users. Having so many people use a pre-release version of a feature means that we’re able to catch edge cases, weird bugs, and gnarly user experience issues that bubble up before we release it to everyone.

When we released the Listings Manager redesign to a prototype group, we wondered things like:

  • If we repeatedly got feedback on something in usability testing, were we able to successfully fix it, or was it still an issue?
  • Is it faster to edit listings in the new Listings Manager? If not, what are the biggest points of friction?
  • What tasks are sellers trying to perform when they switch back to use the old version of the Listings Manager? Why did they switch?

We added some new image editing tools for sellers’ listing images, but noticed that the tool icons were crowding the images interface. Our solution for this was to roll the actions up into a small dropdown. When we put these updates through usability testing, nothing noteworthy came out about the new interface, so we moved forward with it.

After sellers in the prototype group started using it, however, we saw consistent negative comments in the forums about the new dropdown. To create a new listing, sellers tend to copy an existing listing as a template, then edit attributes such as the photos and title. In the old design, editing photos was a straightforward flow, but the new dropdown added in two clicks, more reading, and extra mouse movement. We had created more friction for sellers adding new listings.

The prototype group allowed us to catch issues like this because sellers were putting our product through realistic scenarios. We spent the next six months fixing problems that came directly out of the prototype group. Having a direct line of communication with our beta-testing sellers helped us find patterns, identify problems, and vet solutions before our full release.

Release

When a feature is fully functional and any design kinks we’ve uncovered have been smoothed over, we’ll often release it as an experiment: we’ll direct a portion of traffic to a different version of a page or a flow, then compare metrics like conversion or bounces. What people say anecdotally doesn’t always line up with what they actually do; data helps us understand how people are actually using a new interface.

Etsy’s seller onboarding process is a great place to run experiments because new sellers don’t know how onboarding will work. We’re also able to analyze the long-term impact that onboarding has on a shop’s success. For example, our team noticed that it was taking sellers up to a month to complete the onboarding process and open up their shops, so we began a redesign project to decrease the amount of time it takes to open a shop on Etsy.

At the onset of the project, we defined a number of metrics to determine the success of the redesign, including:

  • the time it took for a seller to go through the onboarding process
  • the percentage of shops that completed onboarding
  • key shop success metrics, such as the number of listings in a shop

We designed another version of onboarding that was solely about getting the basics of a shop—shop name, items, payments—in place. Anything optional, like a decorative banner, return policy, or an About page, could be easily added after the shop opened. We were thrilled with the new interface and simple design, but we wanted proof that this was the right direction.

It’s a good thing we tested the new onboarding against the old. When the results of the experiment came back, we saw that more people were completing the new onboarding (good!), but the number of listings per shop was down (bad!). We had over-optimized and made it too easy for new sellers to go through onboarding. The data from the experiment uncovered design flaws that we never would have found otherwise.

Share early and often


Becoming comfortable with showing unfinished design work isn’t easy. As designers, we’re tempted to want to exhibit control over our work. But by waiting until the very end, we’re assuming that our decisions are right. There’s so much that we can learn early on from the people who use our products. Ultimately, we want to be confident going into a launch that our users won’t feel surprised, confused, or ignored.

Successful product launches are a direct result of continual research throughout a project. Using a variety of methods to get feedback at different points in the process will help surface a range of issues. Addressing these issues will bring your product that much closer to meeting your users’ needs. Don’t wait until design decisions are solidified to ask what your users think. If you ask questions at the right times along the way, you’ll be surprised by what you learn.



via planetweb

Google Unveils Restructuring

Google Inc. is adopting a new structure that makes it more of a holding company, giving the main Web businesses more independence while providing more transparency into executives� ambitious investments and spending on research. Alphabet Inc. will be the name of what will effectively be a new holding company. Google Inc. will be part of that and include YouTube, Android mobile software and other Web-based products. Alphabet will also include Calico, Google Ventures, Google Capital, Google X and other subsidiaries, the Web company said in a blog post Monday.

via planetweb

lundi 10 août 2015

Rewards and Risks of Changing to Hierarchical URL Structure

WebmasterWorld Members discuss the pitfalls and benefits of changing hierarchical URL structure.

via planetweb

Firefox Exploit in the Wild: Mozilla Patches With V39.0.3

Mozilla has moved swiftly to patch an exploit to Firefox which was discovered in-the-wild.

via planetweb

Bing Search to Warn of Unsafe Online Pharmacies

Bing to add warnings in SERPs over "unsafe pharmacies" in a similar way it warns of sites with suspected malware.

via planetweb

jeudi 6 août 2015

Google Updates and SERP Changes - August 2015

WebmasterWorld's monthly look at Google's SERPs changes.

via planetweb

New Google Search Analytics API

Google's Search Analytics API is now ready and available.

via planetweb

Lyza Danger Gardner on Building the Web Everywhere: The Tedium of Managing Code

There’s a place motivation goes to die for web developers. It’s when something we have to do is simultaneously very, very hard and very, very uninteresting. You know, the corner of Hard and Boring Streets in downtown Must-Ship-to-Clientsville. In my personal map of life, that’s the intersection where you’ll find anything that has to do with client-side JavaScript packaging and dependency management.

I have some slides about this in recent talks. They always cause a stir. On one occasion, I had to pause for people to finish cheering. Not at me, but at the notion. There was, I think, relief and amusement at the shared recognition that bundling up and managing our client JavaScript is challenging and, at least for some of us, not our favorite thing to endure.

What are we trying to do here?

A first clue to the wide-flung nature of this beast is that I don’t even have a concise term for what I’m talking about. The summarized goal is that we need to get our various bits of JavaScript put together in a way that a browser can use it. This actually entails several things, as we’ll see, but it can feel like one general objective.

We have left behind the rickety old days, when we wrote and downloaded scripts, tossed them in a directory and stuck them in <script> tags in our web pages. We’re making For-Real Things with JavaScript nowadays, and that comes with the baggage of needing to package, manage, and maintain our code, third-party code, and dependencies.

Starting basic, our first need is to take our application code, package it into one (remember: staying basic here) file, and output it somewhere. Then we can reference the output package in a <script> tag.

This may sound like an exercise in concatentation. But to get distracted by concatenation is to miss the actual thrust of what we need to do: make our code modular and handle dependencies.

You can depend on this

We write code, and as we write it, bits (I’m not going to say modules just yet because that comes in a minute—hang on) of our code need other bits of code from other places. Those needed things—dependencies—might be within our own codebase or external to it.

A primary task is not just to smoosh all of our code together in a package, but to resolve and load the dependencies it needs as part of that process.

That means we need to be able to reference the dependencies we need in a way the packaging tool understands, and the tool needs to know how to find them. Not only that, our code and the code of our dependencies needs to be modularized in the right shape or our tool will rage quit.

Keeping it contained

That is, our code and its dependencies need to use the appropriate module syntax. This is fine when everyone is in the same universe and gets along well, as in the case of pairing npm modules with the popular browserify tool.

browserify can seem so simple and magical. require npm modules that you need in your code just like in node, then bundle it up and, whammo, it spits out a script that works in the browser. So far, so awesome.

But code is modularized and written in different ways—AMD, UMD, CommonJS—or not at all. Some of it might be ES6 (JS 2015 to the cool kids), which we need to transpile.

“Just shim it” and other things easier said than done

There are methods for subduing or translating modules that are in the wrong shape for your packaging tool of choice—packaging tools can be extended or configured to shim wayward modules. But the overhead of managing for many different flavors of modules can be a tedious addition to an increasingly cumbersome process.

Meanwhile, we have additional things to deal with. We also have to manage the source of code and dependencies. Not everything we need for the web comes from npm. Browser-targeted JavaScript has many sources: bower, CDNs, application code from your own repository, third-party code that isn’t managed at all. Fun.

Another common scenario is including a core dependency from a CDN—a classic example is jQuery—within a <script> tag. We need to tell our tool that that dependency is already accounted for, and not to worry about it. And if we can get the config syntax right (grrrr, this one bites me every time), provide that jQuery dependency to our own modules as $ instead of jQuery. Et cetera.

Yes, it’s all very possible

At this point some, maybe many of you are squinting and thinking Come on, it’s not that hard. And, in the grand scheme of things, it’s not. I guess. It’s doable.

But here’s the punchline. Or, at least, the point that makes me want to lie down on the floor for a while. Every single tool or system or combination of tools does each of the things I’ve talked about in a slightly different way. browserify, require.js, webpack, others. Whether that’s the expectation of AMD module syntax or a standalone config file or different command-line options, each solution has its own learning curve that proves remarkably unfun for me when I’d rather be, you know, implementing features. It sabotages my focus.

And then we add more

Any single aspect, like shimming for non-conformant module syntax, can be trivial in isolation, but typically I am at least one layer removed from the packaging by way of a build workflow abstraction. I’m usually looking at my packaging config through a murky lens of gulp or grunt. And often there are other bits at play, like a watch task to spawn packaging builds when relevant code has changed.

It’s a telling sign that the browserify task in my most recent gulp workflows is the only one I don’t fully have a handle on—it’s sourced from a boilerplate example. At one point I went through the code, line by line, and added my own comments, as a learning exercise. For five minutes, I had the whole system glowing and complete in my head. Now I look at the code and it is, once again, soup.

But, ES6!

ES6 (JS 2015) is a significant update to the JavaScript language and has its own, built-in module syntax. And that is great! Especially if we could now go blow up all of the existing code in the world and start over.

Just this morning I was pondering the readme on babel-loader, an ES6 module transpiler and loader. We’ve got a project using webpack and we want to write our own stuff for it in ES6. But now, here I am again. How do I configure webpack correctly vis-a-vis babel-loader? How can I be certain that I can import non-ES6 dependencies into my freshly-minted ES6 modules?

The reality is that even when ES6 support becomes more widespread, there are going to be multiple, co-existing module syntaxes and package managers and unmanaged third-party code. The complexity is a sign that JavaScript has really come of age as the programming language of the web, but mastering this stuff takes some effort. Excuse me while I go off to debug the Uncaught ReferenceError: ufSkpO1xuIl19 is not defined exception that browserify just barked at me.



via planetweb

mercredi 5 août 2015

This week's sponsor: Booking.com

Love travel and design? Our sponsor Booking.comis looking for a new UX designer to join their team in Amsterdam. Apply today!



via planetweb

Yahoo Ads Network Carried Flash Ads Exploit For 7-Days

Hackers used Yahoo's ads network to deliver malicious content to out-of-date versions of Flash.

via planetweb

mardi 4 août 2015

New "Do Not Track" (DNT) Standard Announced by EFF and Coalition

Great to have this standard announced, but will it make any difference?

via planetweb

Love Your CMS. (No, Really!)

“Content management system.” The words are simple enough, but what exactly is a CMS? Is it a simple tool for editing a web page in a WYSIWYG box, or a robust system that keeps track of the historical versions of every sentence on the site? Is it a free piece of software you can install in an afternoon, or a massive purchase that involves contracts and licensing fees and schmoozy dinners with salespeople? Does it help you build a sleek responsive site, or does it thwart you at every turn?

Tragically, the answer is that a CMS is, and does, all of these things. CMSes help and hinder; they inspire rapture and incite table-flipping. I’m thrilled to moderate the next ALA: On Air event, where Karen McGrane, Jeff Eaton, and Ryan Irelan will join me to discuss what they love about working in CMSes (administrative UX!), what drives them to frustration (decoupling!), and what meaty problems (integration with design systems!) they hope to dive into next.

Event details

This event is free and everyone is welcome—just sign up to receive the viewing instructions. Here are the details:

Tuesday, August 25
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 none other than YOU. We’ll also share the full video and transcript after the live show ends.

Join our email list to get updates when new events are announced.

Panelists

Get More CMS Knowledge from Pantheon

Our generous sponsor Pantheon wants you to love your CMS, too. That’s why they’ve created a platform for building, launching, and running Drupal and WordPress sites—all from a single, powerful dashboard.

They’ve also put together a detailed guide to understanding one of the biggest trends in backend dev: the “headless CMS.” Don’t worry, it’s not a spooky story meant to scare off content editors. It’s an approach to decoupling your CMS interface from your front-end experience—and it can help you with everything from redesigning without re-implementing your CMS to finally curing your site of that bad case of div-itis.

Learn more about going headless: how it works, what it takes to set up, and why you might want to try it. See Pantheon’s guide now.



via planetweb

The First Firmware Worm That Attacks Macs

The World's first firmware worm that's vicious enough to break through Apple's legendary security.

via planetweb

The Windows 10 Torrent Network

Windows 10 appears to be a peer-to-peer network for future Windows updates, by default. WebmasterWorld Members show how to disable the capability to help protect system integrity and user bandwith.

via planetweb