vendredi 31 juillet 2015
Google To Defy France's Request for Global "Right to be Forgotten"
via planetweb
jeudi 30 juillet 2015
Facebook Second Quarter 2015 Results, $4.04B Revenue
via planetweb
mercredi 29 juillet 2015
This week's sponsor: Squarespace
Make a beautiful website with our sponsor, Squarespace. Keep it simple, or customize your HTML, CSS, and JavaScript with the Developer Platform—you can even get all your content through the JSON API. Get started today.
via planetweb
Windows 10 Available in 190 Countries Today
via planetweb
mardi 28 juillet 2015
Server Farms - July 2015
via planetweb
2015 Summer Reading Issue
Summer is halfway over. Have you hid out for a day of reading yet? Grab a shady spot and a picnic blanket (or just park it in front of the nearest AC unit), turn off your notifications, and unwrap this tasty treat: our 2015 summer reader.
Refresh your mind, heart, and spirit with this curated list of articles, videos, and other goodies from the recent past—from A List Apart and across the web.
Which web do we want?
Is the web “a place to connect knowledge, people, and cats,” or do “hordes threaten all that we have built for one another”? Where will native-versus-web fights end up? And why are we all here, doing this work, anyhow?
From us
- Ross Penman, Let Links Be Links | March 31, 2015
- Jory Burson, Standardization and the Open Web | April 21, 2015
- Rian van der Merwe, Why? | April 22, 2015
From elsewhere
- Maciej Ceglowski, Web Design: The First 100 Years
- Doc Searls and David Weinburger, Internet Under Fire Gets New Manifesto (Medium)
- Hossein Derakhshan, The Web We Have to Save (Medium)
- Chris Wilson, The Web is Not Poor Man’s Native
Toward an inclusive industry
This web is what we make of it. We can use it to insult strangers in a comments field, or to fight for greater fairness and opportunity in our world. We are inspired by those who choose the path of inclusion:
From us
- Christina Wodtke, Tweaking the Moral UI | December 16, 2014
- Sara Wachter-Boettcher, We (Still) Have Work to Do | May 29, 2015
- Anna Debenham, Making Our Events More Inclusive For Those Under 21 (and Also Everyone Else) | September 29, 2014
From elsewhere
- Erin Kissane, Codes of Conduct
- Victor Yocco, The UX of Alcohol Abuse (Model View Culture)
- Nina Alter, Diversity 101: The How (Medium)
Trying out new techniques
Today’s code is so complex no individual can master it all—but that also means there’s always something new to learn…like these new, niche, or just plain cool techniques.
From us
- Heydon Pickering, Axiomatic CSS and Lobotomized Owls | October 21, 2014
- Sara Soueidan, CSS Shapes 101 | April 29, 2014
- Tingan Ho, Pluralization for JavaScript | March 17, 2015
- Jeff Lembeck, Getting Started with Gulp | December 22, 2014
- Jason Rodriguez, Can Email Be Responsive? | May 13, 2014
Speeding up
Big, lumbering websites, endless load times, and crappy experiences on mobile? No, thanks! Here’s to those in the trenches of performance, fighting the good fight.
From us
- Santiago Valdarrama, One Step Ahead: Improving Performance with Prebrowsing | August 19, 2014
- ALA Event, Designing for Performance | February 26, 2015
- Scott Jehl, Planning for Performance | November 25, 2015
From elsewhere
- Tim Kadlec, Performance Budget Metrics
- Yesenia Perez-Cruz, Design Decisions Through The Lens Of A Performance Budget (Smashing Conference)
Accessibility for everyone
“The power of the Web is in its universality,” Tim Berners-Lee once said—and that means working for all kinds of people, with all kinds of abilities. Let’s stop leaving accessibility for last, and instead start from a place that embraces the needs of all our users.
From us
- Anne Gibson, Reframing Accessibility for the Web | February 3, 2015
- Andrew Hoffman, Accessibility: The Missing Ingredient | May 13, 2014
From elsewhere
- Sara Hendren, All Technology is Assistive (Medium)
Working better, together
What comes after static comps and toss-it-over-the-wall processes? We’re still figuring that out—but one thing’s for sure: people are at the center.
From us
- Katie Kovalcin, 80/20 Practitioners Make Better Communicators | March 17, 2015
- Mark Llobrera, Prototyping Your Workflow | June 3, 2014
- Garin Evans, The Specialist-Generalist Balance | February 17, 2015
- Amanda Costello, The Specialized Web: Working with Subject-Matter Experts | October 21, 2014
- Emma Jane Hogbin Westby, Running Code Reviews with Confidence | September 2, 2014
- ALA Event, Responsive Style Guides | June 16, 2015
- Matt Griffin, The People are the Work | January 22, 2015
From elsewhere
- Mandy Brown and Kaeti Hinck, Remote Control (Source)
Becoming mentors
The more we teach, the more we learn—and the more our industry benefits. Discover the joys of mentoring and the future of web education.
From us
- Georgy Cohen, Cultivating the Next Generation of Web Professionals | November 18, 2014
- Alice Mottola, Initiation to Code | March 31, 2015
From elsewhere
- The Web Ahead, Web Design Education with Leslie Jensen-Inman
- Big Web Show, Those Who Can Teach with Jared Spool
Getting content right
In the beginning was content—and it’s the core of every experience we design and build. Connect the right person to the right content at the right time using strategy, design, and writing.
From us
- Ida Aalen, The Core Model: Designing Inside Out for Better Results | January 6, 2015
- Gerry McGovern, What Really Matters: Focusing on Top Tasks | April 21, 2015
- Eileen Webb, Training the CMS | October 7, 2014
- Jeff Eaton, The Battle for the Body Field | February 25, 2015
- Allen Tan, Gardens, Not Graves | July 29, 2014
- Senongo Akpem, Building Nonlinear Narratives for the Web | May 5, 2015
From elsewhere
- Nicole Fenton, Interface Writing: Code for Humans
The evolution of type
If not yet ubiquitous, sophisticated typography on the web is now at least possible. It continues to evolve apace—virtually anything we could do in print, we can now do on screens.
From us
- Andrew Johnson, Live Font Interpolation on the Web | January 20, 2015
- Nick Sherman, Variable Fonts for Responsive Web Design | January 23, 2015
From elsewhere
- Tobias Frere-Jones, Typeface Mechanics 001
- Kenneth Ormandy, Efficient Web Type Circa 1556
- Tanvi Misra, Can Google Build A Typeface To Support Every Written Language? (NPR Code Switch)
via planetweb
lundi 27 juillet 2015
Google Requires Publishers To Get Cookie Consent From EU Visitors From Sept 30
via planetweb
Google+ Roll-Out: Using Google Without a Google+ Profile
via planetweb
Google Autocomplete API To Become Restricted From 10 August, 2015
via planetweb
vendredi 24 juillet 2015
Google Claims All Top Level Domains (TLDs) Treated the Same.
via planetweb
jeudi 23 juillet 2015
Google Panda 4.2 Rolling Out
via planetweb
mercredi 22 juillet 2015
This week's sponsor: Bushel
If you manage and protect Apple devices at work, our sponsor Bushel is here to help make it easier.
via planetweb
Developing Empathy
I recently wrote about how to have empathy for our teammates when working to make a great site or application. I care a lot about this because being able to understand and relate to others is vital to creating teams that work well together and makes it easier for us to reach people we don’t know.
I see a lot of talk about empathy, but I find it hard to take the more theory-driven talk and boil that down into things that I can do in my day-to-day work. In my last post, I talked about how I practice empathy with my team members, but after writing that piece I got to thinking about how I, as a developer in particular, can practice empathy with the users of the things I make as well.
Since my work is a bit removed from the design and user experience layer, I don’t always have interactions and usability front of mind while coding. Sometimes I get lost in the code as I focus on making the design work across various screen sizes in a compact, modular way. I have to continually remind myself of ways I can work to make sure the application will be easy to use.
To that end, there are things I’ve started thinking about as I code and even ways I’ve gone outside the traditional developer role to ensure I understand how people are using the software and sites I help make.
Accessibility
From a pure coding standpoint, I do as much as I can to make sure the things I make are accessible to everyone. This is still a work in progress for me, as I try to learn more and more about accessibility. Keeping the A11Y Project checklist open while I work means I can keep accessibility in mind. Because all the people who want to use what I’m building should be able to.
In addition to focusing on what I can do with code to make sure I’m thinking about all users, I’ve also tried a few other things.
Support
In a job I had a few years ago, the entire team was expected to be involved with support. One of the best ways to understand how people were using our product was to read through the questions and issues they were having.
I was quite nervous at first, feeling like I didn’t have the knowledge or experience to adequately answer user emails, but I came to really enjoy it. I was lucky to be mentored by my boss on how to write those support messages better, by acknowledging and listening to the people writing in, and hopefully, helping them out when I could.
Just recently I spent a week doing support work for an application while my coworker was on vacation, reminding me yet again how much I learn from it. Since this was the first time I’d been involved with the app, I learned about the ways our users were getting tripped up, and saw pitfalls which I may never have thought about otherwise.
As I’ve done support, I’ve learned quite a bit. I’ve seen browser and operating system bugs, especially on devices that I may not test or use regularly. I’ve learned that having things like receipts on demand and easy flows for renewal is crucial to paid application models. I’ve found out about issues when English may not be the users’ native language—internationalization is huge and also hard. Whatever comes up, I’m always reminded (in a good way!), that not everyone uses an application or computer in the same ways that I do.
For developers specifically, support work also helps jolt us out of our worlds and reminds us that not everyone thinks the same way, nor should they. I’ve found that while answering questions, or having to explain how to do certain tasks, I come to realizations of ways we can make things better. It’s also an important reminder that not everyone has the technical know how I do, so helping someone learn to use Fluid to make a web app behave more like a native app, or even just showing how to dock a URL in the OS X dock can make a difference. And best of all? When you do help someone out, they’re usually so grateful for it—it’s always great to get the happy email in response.
Usability testing
Another way I’ve found to get a better sense of what users are doing with the application is to sit in on usability testing when possible. I’ve only been able to do this once, but it was eye opening. There’s nothing better than watching someone use the software you’re making, or in my case, stumble through trying to use it.
In the one instance where I was able to watch usability testing, I found it fascinating on several levels. We were testing a mobile website for an industry that has a lot of jargon. So, people were stumbling not just with the application itself, but also with the language—it wasn’t just the UI that caused problems, but the words the industry uses regularly that people didn’t understand. With limited space on a small screen, we’d shortened things up too much, and it was not working for many of the people trying to use the site.
Since I’m not doing user experience work myself, I don’t get the opportunity to watch usability testing often, but I’m grateful for the time I was able to, and I’m hopeful that I’ll be able to observe it again in the future. Like answering support emails, it puts you on the front lines with your users and helps you understand how to make things better for them.
Getting in touch with users, in whatever ways are available to you, makes a big difference in how you think about them. Rather than a faceless person typing away on a keyboard, users become people with names who want to use what you are helping to create, but they may not think exactly the same way you do, and things may not work as they expect.
Even though many of us have roles where we aren’t directly involved in designing the interfaces of the sites and apps we build, we can all learn to be more empathetic to users. This matters. It makes us better at what we do and we create better applications and sites because of it. When you care about the person at the other end, you want to write more performant, accessible code to make their lives easier. And when the entire team cares, not just the people who interact with users most on a day-to-day basis, then the application can only get better as you iterate and improve it for your users.
via planetweb
mardi 21 juillet 2015
Microsoft releases emergency patch for all versions of Windows
via planetweb
Regaining Google Rankings After a Break From SEO
via planetweb
lundi 20 juillet 2015
Bing Update Is Analytics Referral Segmentation Issue
via planetweb
vendredi 17 juillet 2015
Google Q2, 2015 Results Show $17.7 billion Revenue
via planetweb
jeudi 16 juillet 2015
Nishant Kothary on the Human Web: The Dominey Effect: For the Love of the Web, Learn Swift
I don’t remember the exact moment I fell in love with the web, but I distinctly remember the website that had a lot to do with it: whatdoiknow.org. It was the personal web site of Todd Dominey, a web designer from Georgia (I wrote that from memory without the help of Google).
By most colloquial measures, whatdoiknow.org wasn’t anything spectacular. But to me, it felt perfect: fixed two-column layout, black text, white background, great typography, lovely little details, and good writing. And, it had this background tile—check it out here, compliments of Wayback Machine (“Give it a second!” to load)—that tapped into some primordial part of the brain that erupts in a dopamine fireworks show at the sight of such things. I’m sure Π is somehow involved.
It was 2001 (maybe 2002?), I was in college, and I was considering transferring out of computer science into interactive media when I found Dominey’s site. I immediately knew I wanted to make sites like that (even if I wasn’t sure why), so I submitted my CODO documentation, and walked across campus to the Computer Graphics department.
The universe pushed back, of course.
“Inadvisable,” advised my academic advisor at the time, because “how can you make money designing things?” It was a different time: B.S.—Before Steve. User experience was in its third trimester, and we’d just started feeling its first kicks. The argument against transferring was effectively the same one faced by liberal arts majors when they tell their parents they are going to major in English and minor in Sociology. The data suggested that I would be far less attractive to employers. But I was drawn in.
I had no choice but to succumb to the first, but certainly not the last, Dominey moment of my professional life.
And thus I was introduced to HTML and CSS. It was love at first sight. But unlike a lot of kids who found their home with standards-based front end web design, I’d just walked into a hyperlinked world of Dominey moments. And over the years, I clicked—maybe “tapped” is the more appropriate word for our generation—and followed many of them.
HTML & CSS naturally led me to the world of graphic design. Photoshop and Illustrator entered my life and elated me. Then I wanted a blog. Moveable Type. This in turn led to CGI scripting, i.e. ASP and PHP. JavaScript entered the party as DHTML. And eventually, Flash—which renewed my interest in programming and mathematics, so that I went back to my old CS department and convinced them to let me finish the degree I’d abandoned while I finished up the other one.
One by one, the domineys were falling.
What’s fascinating about these moments, in hindsight, is they were inextricably linked. And much like the web, even when the links disappeared into the horizon as I moved to the next, they affected my career trajectory for the better. It feels magical that my ability to produce letterpress business cards (a Dominey moment) could have any bearing on my public relations skills for convincing the web community that Internet Explorer had had a heart transplant (a part of one of my past jobs). But there’s nothing really magical about that, is there?
After all, feeling excitement for something new, learning it, getting somewhat good at it, and broadening your horizons can positively affect your career, no matter what you do (h/t to every post written about the benefits of side projects).
Signal vs. signal
All that said, the highs from experiencing these moments were inevitably followed by their characteristic comedowns: a mixture of fear, challenge, prejudice, and even dogma. Take my foray into Flash, for instance.
For a standards-based web guy like me, embracing Flash felt like an either-or proposition as I looked around for mentorship. This phenomenon was a byproduct of the Flash vs. Web debate. You just didn’t come across web standardistas who were equally and openly into Flash—Shaun Inman and Dominey (who created SlideShowPro, a ubiquitous Flash-based slideshow app for a time) were prominent exceptions. Unsurprisingly, what Gruber writes about Apps vs. Web applies almost word for word to Flash vs. Web: “If you expand your view of ‘the web’ from merely that which renders inside the confines of a web browser to instead encompass all network traffic sent over HTTP/S, the explosive growth of native mobile apps is just another stage in the growth of the web. Far from killing it, native apps have made the open web even stronger.”
When you take these sort of necessary but paralyzing debates and couple them with the insecurity you feel in answering the tap of a Dominey moment, it doesn’t take much to talk yourself out of it. And that problem never really goes away.
Even today, having quit my job to go out on my own, the pushback is strong. What has changed though, thanks to a healthy amount of experience, reading, thinking, and counsel, is my ability to negotiate the arguments from others and myself as I embrace my next moment, inspired by the ongoing app revolution and the pleasure I derive from developing in Apple’s new language: Swift.
My ability to steer around the doldrums of doubt wasn’t always there, though. Long ago, and often along the way as well, I needed a little nudge from a friend or mentor to get me going.
So finally, on the topic of apps and Swift: let me give you a quick nudge.
A Swift nudge
If you’re a web programmer (or a budding programmer of any kind, or just someone who wants to get into programming), and looking at an app on your device (Instagram, Pinterest, Paper, and iMovie come to mind for me) made you think, “I want to build something like that,” I have this to say to you: learn swift today.
Don’t think twice about it.
This must seem like a bizarre recommendation to make to a group of “people who make websites.” But I’ve never quite taken that tagline literally, and I know far too many of you feel the same (whether you’ll admit it in public or not). We are people who make the web, and as luck would have it we are people who particularly understand designing for mobile.
After immersing myself in it for a year, I find Swift to be deeply web in its soul. From its expressive, functional syntax and its interpretive playgrounds to its runtime performance and recent foray into open source, Swift is the web developer’s compiled language (with the mature and convenient safeguards characteristic of the compiled environment).
Everything you need to get you started is here. It’s free. And the community is amazing.
As you may expect, the universe will push back on you embracing this moment. It will manifest in myriad ways—from the age old question of web vs. native to debates about Swift performance, syntax, and Apple’s intentions.
Ignore that pushback. (Or don’t: do your due diligence, and form your own opinion.)
But whatever you do, if you’ve got that thumping feeling, don’t ignore it. And try to not forget that you’re here because long ago you too embraced a Dominey moment.
As far as I can tell, it’s worked out pretty well for all of us.
Footnotes
- 1. Full disclosure: I do not know nor have I ever met Todd Dominey (but I’d buy him a drink anytime).
via planetweb
Windows 10 will update whether you like it or not
via planetweb
mercredi 15 juillet 2015
Google Announces Test of Purchases, with "Buy on Google"
via planetweb
Google AdWords Estimated Total Conversions Now Measured Across Web and App
via planetweb
mardi 14 juillet 2015
This week's sponsor: Pantheon
Build, launch, and manage all your Drupal and Wordpress sites with help from our sponsor, Pantheon. Register for a weekly demo today!
via planetweb
Mozilla Firefox Now Blocking Flash By Default
via planetweb
lundi 13 juillet 2015
Adobe Flash Critical Vulnerability for Windows, Mac, and Linux
via planetweb
vendredi 10 juillet 2015
Bot ID and Blocking GET xmlrpc.php To Avoid Exploit
via planetweb
jeudi 9 juillet 2015
The Latest Flash 0-day is no Joke
I’m guessing there’s a better than decent chance that you’ve already heard about this, but this is such a bad one I thought I would just make sure: The appropriately-named Hacking Team was hacked earlier this week, and in the 400 gigs of data stolen from them was a previously unknown 0-day Flash exploit. The exploit allows web sites to execute arbitrary code on vulnerable machines.
The Hacking Team makes a living selling tools that allow their clients, mainly governments and law enforcement, to surveil internet users and snoop on encrypted internet traffic. An important part of their service is collecting unknown exploits and keeping them a secret so they don’t get patched, and can continue to be exploited.
Flash gets updated a lot, often for security purposes. What usually happens is a security firm, or a hacker looking for a bounty, or Adobe itself will find a vulnerability, and the Flash team will quietly patch their software before the exploit becomes widely known. This time, the exploit is already out there, and is quickly making its way into malware tools.
So, I assume you’re already multi-tasking and disabling Flash in your browsers. (Here’s how to disable Flash in Chrome. And Safari. And Firefox. And IE.)
And now you should go patch Flash.
via planetweb
Facebook Updates News Feed Control For More User Flexibility
via planetweb
Microsoft Launches Office 2016 for Mac
via planetweb
This week's sponsor: GraphicStock
Graphics, photos, and vectors—oh my! Get a week’s worth of free image downloads from our sponsor GraphicStock.
via planetweb
Facebook Updates How CPC is Measured: Excludes Likes, Shares and Comments
via planetweb
mercredi 8 juillet 2015
Designing for Non-native Speakers
For the past few years, I’ve worked on sites and web apps that have large user groups of non-native speakers of English. That has given me a chance to look at how they are accepted (or rejected) by people who don’t speak English as a first language.
Some curious facts emerge when you compare the languages most sites use, versus the languages most internet users speak. While around half of all web pages are in English, only about 28 percent of the people using the internet speak English as a first language. Interesting, right? There are billions of people who use and browse the English web, but are not native speakers.
Asking for fully translated and localized sites is a mammoth task, one only large international conglomerates can afford. Instead, we can take some other simple steps to make our sites accessible for non-native speakers. We can focus on clear language, interfaces, and prompts, to help users as they navigate a largely English-speaking web.
Readability
A few years back, my coworkers and I were planning the design and launch of a marketing site for one of our new English language courses for adults. We started to gather copy and content. The majority of it described the features of the course and the resources available to teachers. We needed to keep in mind that many of the teachers for this course were not native speakers of English.
In order to get an objective idea of how complex our copy was, we ran it through the Flesch-Kincaid Readability Test. The test measures how difficult a passage in English is to understand, and assigns a score or US-reading level. You can do this with the “Show readability statistics” tool in Word, or by copy and pasting your content into an online tool. Our marketing copy was topping out around the 13th grade level, meaning you needed at least a year of college to understand what we were saying about our product! We should have been sticking to a level of 6th-8th grade to make sure our content was clear and accessible to our customers. No one wants to stumble through dense text just to get info on a new product!
In order to remedy this we needed to take a few basic steps, focusing on our copy, and our UI. First, we ran Flesch-Kincaid scores for all the content. We compared the passages that had lower scores with those that came in very high. Based on that, and what our marketing team needed, we decided to go for a reading level of around 9th-10th grade—clear, but not dumbed down for English teachers. We then created a content map, basically a spreadsheet with all the copy, its location in the site, the reading level, and a few other bits of information. For every place the readability was poor, we edited it down and ran it through the test again, until we were satisfied.
Standardized interface language
Another area where sites and web apps can trip up non-native speakers is in the interface language. Users with varying levels of comprehension employ all kinds of strategies to understand what they are reading. While there are many standard commands like “save” and “help,” other processes, like “upload image from computer” when written poorly, can be confusing for non-native speakers. We should aim to provide them with simple, standardized commands that they can easily read and remember, wherever they are on the site.
So how can we do this? I have found that creating a spreadsheet or list of all your interface language and sharing that with your design team is a great way to maintain a sitewide standard.
This strategy is not only relevant for non-native speakers. All users, regardless of their comprehension levels, need consistent messaging and instructions on your sites and web apps. By focusing first on those with the most pressing needs, you make your site usable for a much wider variety of users.
Support tools
Sometimes though, simplified language is not enough. When we pair icons and text, we increase the speed at which recognition happens. It is an attempt to build a common language, one that is less dependent on English comprehension. But this is easier said than done. Look at these icons in Chinese mobile apps, and try to figure out how many you recognize.
Perhaps we need to offer an additional layer of context in these situations. Let’s start with onboarding. As non-native speakers download and enter your app or site for the first time, it is a great idea to provide small popups or a series of screens with animations to show the functionality. This handholding at the beginning of the experience can provide a sense of clarity and comfort even without a full understanding of the language you are using.
Tooltips next to key actions can also be helpful. At first glance you may think, “If it were designed correctly, you wouldn’t need tooltips!” which is true for native English speakers. But if, like me, your customers are not always native English speakers, then small, unobtrusive explanations next to key actions can provide that continued layer of help that your users need. Some web apps like LayerVault even use progressive reduction, where increased use means less explicit help is displayed, but if a user returns after a long period away, this contextual support is added back into the UI.
Non-native speakers of English often need a little extra help to get through English web interfaces. That is OK. If they are a significant part of your customer base, these are some simple ways to support them, making a more powerful online experience possible. Aligning your readability level with your users’ reading comprehension level, standardizing your interface, and expanding the range of help options available to users are all things you can do now—you don’t need to wait until the future when you have the time and money for a complete overhaul of your content. By planning and delivering these discrete steps, you can do a lot right now to help all your users, whether they are native speakers or not.
via planetweb
New Google Shoping Interface Test... Pools Reviews, Specs, Product Info
via planetweb
mardi 7 juillet 2015
Google Announces Material Design Lite (MDL): A Specification For UI
via planetweb
Google Updates and SERP Changes - July 2015
via planetweb
lundi 6 juillet 2015
Facebook tweaks its logo to be more mobile-friendly
via planetweb
Pinterest Ecommerce "Buyable Pins" Rolls Out to Apple Devices in US
via planetweb
Austrian Court Throws Out Class Action Lawsuit Against Facebook
via planetweb
Google Appears to Have Removed Google+ Posts From Knowledge Panel
via planetweb
Bing Replaces Google on AOL, Microsoft Passes Majority of Ad Sales To AOL
via planetweb
Feedback Phases and Personas
A few weeks ago, I released my first solo app on the App Store, Parking. It’s a small project, but I still sought the help of a few friends before launch for testing and feedback.
Getting valuable feedback is a delicate and very important thing. A little bit of planning ahead of time can go a long way—I don’t recommend sending a beta out to a dozen friends with no thought other than, “Let’s see what they think of it!”
I structure a few phases of feedback, each with defined goals that help work my way toward the final product. For each phase, I try to provide testers enough guidance on what type of feedback I’m seeking, while trying to avoid restricting their free flow of thoughts.
A big focus of mine is introducing new testers at each point—continually having fresh eyes on the product helps immensely. It exposes things that users who are familiar with the product will glance over as part of the rough edges inherent to beta stages.
Beyond the benefit of fresh eyes, I try to map the personas and areas of focus of my testers to the goals of each phase. For the testing and feedback process of Parking, I identified five personality types (with five corresponding phases).
The domain experts
These people are masters of the domain in which you’re working—whether that means the platform or environment, or the audience or market you’re targeting. It’s a good idea to have these people helping out from early on (they’re the first group I bring in), because they can validate the core pieces of your work before it’s too late in the process to make major revisions.
The idea people
This group is a fantastic follow-up to the domain experts. It’s made up of people who understand what you’re building, and are great at brainstorming everything from an entirely new feature to a smaller, but useful addition. Don’t bring this group in too late either, or else their great ideas won’t see the light of day.
The meticulous
These people don’t miss a thing. They evaluate every last detail, every little decision, and will give you a wall of feedback. It’s critical to bring this group in after the core of your product is built and polished with the help of domain experts and idea people, or else this group’s detail-focused evaluations won’t be useful.
It’s especially important to be respectful of this group’s time—they’re going to put a lot of effort into pouring over your work and providing feedback, so make sure you can put that feedback into action quickly.
The breakers
These people can break anything. I’m sure you know a few people like this, if you aren’t one yourself. After polishing the details with the help of the meticulous, have this group help break as much as possible, and then make sure those breakages are fixed, or handled gracefully. This group is the most frustrating by far (in a good way, I promise), but the stability of your product will thank them, and so will you.
The slightly different
This is a group of people that will use your product slightly differently than you imagined, or use technology as a whole in a way unfamiliar to you (whether that means different contexts, locations, devices, or something else). It’s a tough group to put together, but it’s vitally important to expand the way you think about what you build. A different way of using technology brings a different perspective. This group will often see that you’re incredibly close to something they would find very useful—something you’re missing out on altogether—and that can open your product up to an entirely new segment of the market. This is the last group I bring in, once core features are implemented, polish is applied, and bugs are fixed.
Those are the five personas I’ve identified and structured feedback around, though some people may cross over between groups, and that’s great! I often find a strong correlation between the meticulous and the breakers, for instance.
As always, be pragmatic. Feedback phases matched to personas has improved my process, but your product may call for something different. Find what works for you, but be thoughtful about constructing an environment for feedback that works to make your product better.
via planetweb
jeudi 2 juillet 2015
Rachel Andrew on the Business of Web Dev: Software Audits for the Tiny Business
In the dot com boom, I headed up a technical team. One of my responsibilities was the hardware and software needed by our team and other teams in the company. Back then, software was typically boxed and came with packs of licenses. I had an internal software audit routine to check that all of our computers were correctly licensed.
In my own business, I’m part of a two-person team. Many of our software licenses are purchased far less formally and are for one user only. We also rely on a huge amount of Software as a Service, where there is no box or permanent license to use the service. As owner-managers, we sometimes buy something using a personal email address or bank card, despite it being for company use. Also, we contract third parties to do work for us, and they purchase software or create accounts on our behalf. With no physical boxes, or volume licenses to keep track of, small companies now develop websites and software in a far more informal way.
It’s a common pattern we see at Perch: the company contacting us has had a website developed, and sometime later the person who developed the site and bought the software license leaves the company. The company has no idea how to access the license information, and password reset attempts go to a now-dead email address. Sometimes the account is linked to a personal email address, or was even bought by a third party who had been contracted to build the site.
With accounts spread around between owners, employees, and contractors, businesses can easily leave themselves exposed. Services get canceled because no one saw the reminder that a credit card had expired. Domains fail to auto-renew, leaving the company in danger of losing them. Software purchased via an employee or contractor becomes inaccessible due to that person leaving. Therefore, I propose that every business needs a software and services audit. Collate all of this information, then make sure it is accessible to you and other trusted team members.
What should we audit?
What should you take a look at? To get you started, I’ve listed a few key areas that most web agencies and software businesses will recognize. Once you start this process, you will no doubt think of more. (If you think of something other business owners might forget, add it to the comments.)
Domains and DNS
Does the company own all of the domains you use, or are any linked to personal accounts?
Can you move all of the domains and DNS management to one location? Services such as DNSimple offer domain hosting and DNS management, and can be a better choice than having domains registered alongside your webhosting.
Do you have a solid way to track expiration dates? Are domains set to auto-renew with up-to-date payment details? Do all of the domains have correct contact details?
How many email accounts are being used in your business? Are you, or your employees, using personal addresses for company business?
Is important and valuable information stored in your email, or in the email of employees? For example, if you work with clients by email, who has the history of the conversations?
Is email securely backed up?
Software used on your websites
Many websites rely on paid software-whether that is a full CMS like Perch, or paid add-ons to WordPress. Who owns those licenses?
Which email address is linked to these licenses? The developer might use it to let you know of important security updates to the software.
Do you have access details for any account on the third-party website?
Do you know where and how to get support for any of the components of your website that haven’t been developed in-house?
If you develop websites for clients, you may be able to help them to manage this better by providing a handover pack on payment that includes all of the key details and clarifies their significance.
Recurring payments
Go through your bank and card statements. What does your business pay for, monthly or yearly? Cancel anything you don’t use.
For services you do use, check if you can save money and bookkeeping by switching to an annual plan.
Check that the plan you are on is up to date and still the right one for you. SaaS companies often introduce new levels of service—you might save money or get new functionality by switching.
Keep a list or spreadsheet of services and the date on which you last checked them. You can repeat this process every six months, to make sure you don’t pay for things that you are not using.
Start with one small thing
Auditing everything you use in your business is likely to save you time and stress in the long run, but with our limited time it’s an area we can find easy to avoid. You don’t need to do this all at once. Next time you have a couple of spare hours, pick off one area and start there.
In a couple of hours you could list all of your domains, check when they expire and make sure that you can access the registration for each. You may need to add another to do to your list to consolidate them at one provider, or to update contact details. However, you have moved forward just by knowing what the status of your domains is. You are already less likely to have the nasty surprise of waking up to find a website offline due to the domain expiring.
Let me know in the comments if this is an area you struggle with; or if you have found good ways to store, maintain, and share this kind of information.
via planetweb
Facebook tweaks its logo to be more mobile-friendly
via planetweb
mercredi 1 juillet 2015
Pinterest Ecommerce "Buyable Pins" Rolls Out to Apple Devices in US
via planetweb
Austrian Court Throws Out Class Action Lawsuit Against Facebook
via planetweb
Google Appears to Have Removed Google+ Posts From Knowledge Panel
via planetweb
This week's sponsor: TeamGantt
Our sponsor TeamGantt wants to help you organize your projects better. Check out their 30-day free trial to get started.
via planetweb