HOME > RSS > TECHNOLOGY > Jeffrey Zeldman Presents: The Daily Report

R S S : Jeffrey Zeldman Presents: The Daily Report

PageRank : 4 %

VoteRank :
(0 - 0 vote)

tagsTags: , , , , , , , , , , , , , , , ,



Spotify to music subscribers: drop dead

9 October, by Jeffrey Zeldman[ —]

SINCE AT LEAST 2010, subscribers to Spotify’s paid music service have asked the company to include the ability to sort playlists alphabetically in the desktop player. It’s the sort of drop-dead obvious feature that should have been built into the player while it was still in alpha. Yet, after six years of requests by paying customers, the feature still does not exist. Many good people work at Spotify and take pride in working to create the best possible music service. But the management in charge of feature requests does not seem to care about or respect customers.

Spotify subscribers organize their music in playlists. Any serious music listener will soon have dozens, if not hundreds, of playlists. They appear in the sidebar in reverse chronological order of the date of their creation. From a programmatic standpoint, the order is random. The inability to sort playlists alphabetically soon makes listening to one’s entire collection problematic. You ignore most of your playlists because you can’t find them, and waste time recreating existing playlists because you’ve forgotten they exist—or can’t find them.

For years, Spotify users have taken to the company’s message boards to request that this basic, rudimentary, obviously necessary feature be added. And for years, Spotify’s official message-keepers have strung users along. Reading these message boards is a study in corporate indifference. In this board, for example, which began in 2012, one customer after another explains why the ability to alphabetize their list of playlists is necessary if they are to continue using the service. It’s almost comical to watch the customer support folks react to each post as if it is a new idea; or attempt to pacify the customer by assuring her that staff is “working around the clock to implement this feature.” That last comment was made in 2015, three years into the thread; there’s been no word about the feature since.

The desktop player does let users change the order of a given playlist by dragging it up or down. That feature would suffice for someone who had three playlists. It might even work for someone with a dozen playlists. But for someone with several dozen or more playlists, manual drag and drop is not only no solution, it’s actually insulting.

What Spotify has done is create an all-you-can-eat buffet, and equipped its customers with a toothpick in place of a knife and fork or chopsticks.

The problem can’t be that difficult to solve, as Spotify has added alphabetization of playlists to its phone and tablet apps. Yet the desktop, a primary source for folks who listen to music while working, remains as primitive as it was in 2010.

Six years of alternately pretending not to know that your paying customers require a basic tool to manage their subscriptions, and pretending to be working on a solution, shows a basic disregard for the paying customer. Which kind of goes along with a disregard for the working musician, who isn’t exactly getting rich off the Spotify royalties that have replaced CD sales.

Apple Music has rubbed me the wrong way since Apple first crammed it into their increasingly dysfunctional iTunes player (whose poor usability is what drove me to Spotify in the first place). I hate that Apple Music shows up on all my Apple devices, even though I don’t subscribe to it, and even after I’ve turn it off in Settings. In this regard, Apple today is like Microsoft in the 1990s. And I don’t mean that in a good way.

But, as obnoxious and overdesigned as it is, there’s one thing I like about Apple Music: it just may drive the complacent management at Spotify to actually start listening to their customers.

The post Spotify to music subscribers: drop dead appeared first on Zeldman on Web & Interaction Design.

Ten Years Ago on the Web

22 September, by Jeffrey Zeldman[ —]

2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugsworrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.

I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.

Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)

Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.

Other sites we designed that year included Dictionary.com and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.

I was reading Adam Greenfield’s Everyware: The Dawning Age of Ubiquitous Computing, a delightfully written text that anticipated and suggested design rules and thinking for our present Internet of Things. It’s a fine book, and one I helped Adam bring to a good publisher. (Clearly, I was itching to break into publishing myself, which I would do with two partners a year or two afterwards.)

In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.

As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts onetwothree, or four, have a look back.



The post Ten Years Ago on the Web appeared first on Zeldman on Web & Interaction Design.

Speaking Most Clearly When Not Speaking At All

9 August, by Jeffrey Zeldman[ —]

Writing brain and speaking brain verbalize differently for me, I have found. I’m considered a passable conference speaker, and, from friendly conversations to client meetings, I’m rarely at a loss for words. But the ideas I’m able to articulate with my mouth are nothing, absolutely nothing, to those I can sometimes share while writing.

In writing I have clarity of vision and authority of tone that I almost completely lack when speaking with more than one person at a time. This is why I often find meetings stressful and frustrating.

Now, meetings are essential to design and business. And they’re great for listening and learning. But when I have a strong point of view to put across, or when am trying to align folks around an important rallying point, conversation with more than one person just doesn’t cut it for me.

Rooms hurt.

The more of my businesses and projects I can wrap around written communication, the more optimistic I am that those businesses and projects will grow in meaning, deepening their connection to people and serving them better and better. And the more the business of running a business relies on person-to-person talk, the tougher it gets for me to be sure things are progressing toward clear and meaningful goals.

I sense that probably many designers feel this way.

Oddly, I probably don’t come across as one of these designers, because I do okay in a meeting. I’m not the cliched tongue-tied designer in the corner. My relative articulateness as a designer has been a cornerstone of my success, such as it is. In meetings I may even speak too much. Not from lack of interest in what others have to say, but out of fear that an idea not expressed will be lost. This anxiety that drives me to verbalize probably makes me appear confident. Maybe even over-confident.

But my seeming ease in meetings is nothing to the comfort, clarity, and articulateness I feel when alone at a keyboard.

I speak for myself now. This is just me. This is not a law of design or business. Not a rule. Not a lesson. For some folks—including some of my smartest and most productive collaborators—the hack of emitting sounds through flapping jaws is how the best ideas are birthed. And more power to them.

Learning to be okay with their process is part of my challenge as a worker and person. It’s a challenge because it’s a surrender of control as well as confidence. We are all here to share something. In writing, I know what I must say and how to say it. In a room, I’m a person struggling to focus, my monkey mind sabotaging me as it tries to claw its way out of the room.

I would not have figured this out about myself if I didn’t have a gifted child who is also ADHD and dyslexic, calling my attention to how completely differently different individuals can process written and spoken English, and making me realize that, like my daughter’s, my brain is also more comfortable in some verbal environments than others.

I acknowledge that part of what makes written communication work for me is the solitude. Perhaps I’m more narcissistic than I hope. Or maybe it’s just that silence is the place where I can hear whatever it is that I’m meant to share.

The post Speaking Most Clearly When Not Speaking At All appeared first on Zeldman on Web & Interaction Design.

Sometimes a cigar is a penis

10 July, by Jeffrey Zeldman[ —]

Beach photo

MANY NIGHTS I have these dreams where I lose my daughter while traveling. We’re about to board a flight, and suddenly she has vanished. In other parts of these same dreams, still traveling, I’m doing something amazing—like hiking the Alps—when I realize I’ve forgotten to check in on my app. Although the two distresses are in no way equivalent in life, in the dream sudden heart-stopping panic attends them both. It’s as if my unconscious is warning me I place too high a value on my illusory digital life.

There’s also baggage in these dreams. Literal baggage. As in, before boarding the flight with my daughter, I need to pack all our household possessions, so they can fly with us to a new home. In reality, we live in a two-bedroom apartment. In the dreams, the possessions fill a huge, rambling house. They are mostly dirty and broken: a cracked hobbyhorse, a single-octave air-powered toy organ with chord buttons. Halfway through wrapping these smashed globes, armless dolls, and hand-me-down suitcases that cannot be closed, I wonder why I must drag all this baggage with us.

In my 20s, I had a different recurring dream. In that one, I was at the beach with my father the moment before an immense tidal wave came crashing down, annihilating all life. I would see us from an overhead omniscient point of view—all of us beachgoers gazing up wordlessly at the power that was about to smash us out of the universe. Then, from my own point of view, I would gaze for an endless moment at the peaking wave, which seemed to hang suspended for a miniature eternity. Unable to bear my terror, I would turn to my father and bury my face in his chest. The last thing I experienced in the dream was my father’s hand cradling the back of my head.

I had that dream over and over. At the time, it seemed to me an omen of imminent tragedy. Now I think it was simply the disguised expression of a wish to know my father’s love and feel close to him.

My father is of that generation that doesn’t hug and doesn’t easily share its feelings. Today he is finally old enough, and sentimental enough, to say, “Ditto, kid,” when I tell him I love him at the end of our phone calls. We speak more now than we did all the years I was growing up. Night school, and two jobs, and other things kept him away far more than he was home.

Now in life I am a father, living alone with my daughter, two cats, and four hamsters, in an apartment that, on good days, looks like a dozen children must live there. On bad days, it looks like the Gestapo came through. Come to think of it, at age twelve I had recurring dreams about hiding from the Gestapo.

There’s the surface world, where we worry about work and bills and if our kid is getting enough nutrition. And why some people we like don’t like us. And why some people we were kind to hurt us. And whether we are kind enough. But mainly about work and bills and food.

And then there is the dream world, where our true fears stand naked, telling us who we are, and what we value.

Also published in “Let Me Repost That For You” on Medium.

The post Sometimes a cigar is a penis appeared first on Zeldman on Web & Interaction Design.

Help Carolyn Wood

17 June, by Jeffrey Zeldman[ —]

Carolyn Wood needs your help.ONE OF THE NICEST web professionals I’ve ever worked with desperately needs and deserves our community’s help, compassion, and kindness.

Many of you, whether you knew it or not, have benefited from Carolyn Wood’s work on A List Apart, Digital Web, The Manual, and Codex: the journal of typography. For two decades, she has been a tireless, egoless motive force of great projects—always eager to help, never seeking the spotlight.

Now she needs our help. Like nobody ever needed help before. Catastrophic medical problems, together with lack of support from the insurance system, have left Carolyn in a life-or-death crisis. Only by our whole community pulling together can we hope to raise the huge sums Carolyn will need to survive.

Please help by donating what you can, and by sharing Carolyn’s support page with anyone in your network who is compassionate and will listen.

Life is often unfair. But a network of caring, compassionate web folk can send a ray of light into Carolyn’s undeserved lonely darkness. I know we can do it!

Please donate, and please share Carolyn’s page with your Twitter followers, Facebook friends, and the actual human beings you know: www.youcaring.com/carolyn-wood-585895.

The post Help Carolyn Wood appeared first on Zeldman on Web & Interaction Design.

Introducing studio.zeldman

13 June, by Jeffrey Zeldman[ —]

STUDIO.ZELDMAN is open for business. It’s a vision I’ve been cooking up, a new studio supported by some of the most talented people in our industry and everything I’ve learned in two-plus decades of web and interaction design. And now it’s here. studio.zeldman designs digital experiences and provides strategic consulting. We don’t have a portfolio yet, but we landed our first client before we launched. Come on down!

The Design

Heading in this direction meant leaving the studio I founded in 1999 (we’re on the best of terms, and it’s an excellent company in great hands). My rise to an almost purely strategic position there taught me a lot about my business—but it also kept me from designing new projects. And I’ve been itching to get back to my roots. Three factors shaped my design for the new studio’s website:

  1. I wanted to try something different: something that was conceptual and art directional. Jen Simmons’s An Event Apart presentations (like this one from last year) inspired me to break out of the columnar rut of current design and create something that didn’t look like it came pre-baked in a framework.
  2. Because I am contrary, I thought it might be fun to allude to an outdated design approach (like, say, skeuomorphism) in a responsive web layout—if the content supported such a gambit.
  3. Most of all, my design had to come out of content.

Let’s unpack that third point a bit more. Normally, design studio websites discuss the customer’s business problems and posit design (and their particular skills) as the solution. It’s a strategy David Ogilvy pioneered for print advertising in the 1950s (“problem/solution”).

Every mention of an achievement or capability exists to show how it solved a client’s business problem: “our redesign increased conversion by 20%” or “our testing and iterative process reduced shopping cart abandonment by 37%,” and so on. Such sites talk about the company’s expertise, positioning it within a framework of client needs. Almost every design studio says the same two or three things at the top of their home page, leaving the real selling to their site’s case studies section. But studio.zeldman is new. No portfolio yet; no company history.

But first, a little something about me

With no portfolio, our strategy—at least for the launch—couldn’t be about our body of work. At least for now, it had to be about me: what I believe, what I’ve done. I came to that realization very reluctantly: I wanted to create a studio that was bigger than any one person. (My original name for the company was simply “studio,” and my plan for the design was that it should be as clean and basic as water.)

But Jason Fried of Basecamp, who is one of my smartest friends, persuaded me that what was unique about this new studio was me, and that I shouldn’t be afraid to say so. Jason convinced me to write simply and directly, in my own voice, about what I believe design is and does—and to support that message by showing some of the things I’ve done that reach beyond my portfolio.

As if I were sitting down to send you a personal note about this new company I’m starting, the best way to express those thoughts on the site was in a letter. That was the strategy. The letter was the idea. And the idea shaped the design.

A new angle on an old design idea

In 2007, if I were designing a site that began with a letter to the reader, I would have used drop shadows and paper textures to suggest that context. Back in 1995, I’d have made an image of a letter on a table or desk top, and the letter would have been at a slight angle, as if the writer had just left it there. Could I allude to these old-fashioned ideas in a way that was subtle and modern?

The 1995 technique of a photorealistic letter was out. But a slightly angled “paper” was feasible; Jen Simmons had shown me and hundreds of other people how this kind of thing could be achieved in modern CSS.

Of course, whether something is possible in modern browsers and whether it actually reads well can be two different things. So while I was comping in pen and paper and in Photoshop, we also ran tests. My collaborator Roland Dubois set up a CSS3 font-smoothing test for angled text in JSFiddle, while my friend Tim Murtaugh of MonkeyDo put together a quick prototype of the top portion of my initial design. Everything checked out.

Once I knew an angled letter could work, I made the angled placement and angular cropping of images a guiding principle and unifying idea for the rest of the design. On the calendar, it took me from January through April of this year to land on a design idea I liked. But once I had it, the site seemed to design itself in just days.

I confess: yes, I designed in Photoshop. (Don’t tell anyone, but I even started with a grid.) And, yes, to your horror, on this project I designed for big screens first, because that’s where these particular design ideas could be most impactful. I knew we could make the design sing on any size screen, but designing for big-screen-first brought this particular project’s biggest coding challenges to the fore and provided the excitement I needed to get to the finish line. Nothing brings a smile to a designer’s lips like seeing your web idea completely fill a 27-inch screen (and do it responsibly, even).

The best part

The best part of the page is the part I didn’t design. Roland did. It’s that magical form. I could play with that thing forever, and I hope potential clients feel the same.

Some folks who checked out the beta asked why we didn’t focus on specific capabilities or budget ranges. Fair question. We certainly could have launched as, say, a redesign shop, or a web-only studio, or a content-focused studio. Any of those would have been credible, coming from me, and differentiating ourselves right out of the gate would not have been a stupid move. We really thought about it.

But we decided it would be more interesting to be less specific and find out what our potential clients are actually looking for. Consider it research that might sometimes lead to a gig.

studio.zeldman thanks you

Mica McPheeters and Jason Fried checked out my copy and kept me honest. Tim Murtaugh coded an early prototype of the site. Roland Dubois coded the final from scratch. Noël Jackson set up the repository and CDN, and ran sophisticated tests that uncovered everything from bugs to performance issues, rebuilding and re-coding with Roland to squeeze every byte of performance we could out of a site with full-screen Retina images. An article by Roland and Noël on the experiments and techniques they used to code this site would be infinitely more interesting than what you’ve just read.

Hoefler & Co. designed the reliable letter font which you will all recognize as Sentinel; DJR created Forma, which I think of as sexy Helvetica, and let us use it even though it is still in beta. Before launch, to save bandwidth, we tried recreating the site design using system fonts. Wasn’t the same. (And with WOFF and CDNs and subsetting, we were able to deliver these wonderful faces without choking your pipes.)

Our thanks to the beta testers: Andrew Kirkpatrick (above and beyond the call of duty on matters of web accessibility), Rachel Andrew, Jen Simmons again, Anna Debenham, Jeremy Seitz, and Nicholas Frota. And to Anil Dash, Jessica Hische, Jessica Helfand, and Khoi Vinh, who gave us design feedback prior to launch.

Most of all, thanks to the “Royal Advisors” who put up with my endless changes of mind, and who always acted as if they were pleased to check out my newest brainstorm, or listen to my latest circular argument: Sarah Parmenter, Jason Fried, Fred Gates, Jen Simmons, and Mike Pick.

The post Introducing studio.zeldman appeared first on Zeldman on Web & Interaction Design.

Has Design Become Too Hard? – transcription

http://www.zeldman.com/2016/06/05/transcription-design-become-hard/play episode download
5 June, by Jeffrey Zeldman[ —]

What follows is a transcription of Has Design Become Too Hard?, which I wrote for Communication Arts in June 2016. I transcribe it here against the day CA takes down its content.


WE DESIGNERS love to complain. It’s our nature. After all, if we were satisfied with the way things work, feel, and look, we wouldn’t have become designers in the first place. But lately, particularly among web and interaction designers, our griping has taken on a grim and despairing flavor. Digital design is not what it used to be, we say. The fun has gone out of it. An endless deluge of frameworks and technologies has leached the creativity out of what we make and do, and replaced the joy of craft with a hellish treadmill of overly complicated tools to master.

Many of us feel this way, but is it true?

Consider responsive web design, proposed six years ago (video) by Ethan Marcotte at An Event Apart, and subsequently turned into an article and then a book. In twenty-plus years, I’ve never seen a design idea spread faster, not only among designers but even clients and entire corporations. Companies brag about having responsive designs for advertising, for crying out loud. Yet, after a euphoric honeymoon, designers soon began complaining that responsive design was too hard, that we’d never faced such challenges as visual people before. But haven’t we?

In the early days of web design, beginning in 1995, pixels were not standardized between PC and Macintosh; monitor aspect ratios were not standardized, period; and when we got a standardized layout language for the web, every browser supported it differently for years.

We tried “liquid layout” to work around the fact that every monitor was different. Our clients demanded we put everything above the fold, and we acted as if there was one—a consensual hallucination, when there were as many folds as there were screens, browsers, and user-adjustable settings.

Later, when standards were better supported in browsers, some of us pretended that “everybody” had a 600 x 400 monitor (and then an 800 x 600, and then 1024 x 768), but these too were consensual hallucinations. And even in those rose-colored fixed-width days, there was always a client or a QA tester whose user preference settings, outdated browser, or wonky operating system blew our carefully constructed fixed-width layouts to hell.

Good design was never easy. The difference between now and then is that today, instead of pretending or wishing that everyone used the same platform with the same settings to view print-perfect digital masterpieces, we acknowledge that people will access our content however they choose, and with whatever device they have close at hand—and we design accordingly. For the first time since people first argued over how to pronounced “GIF,” we’re designing with the medium instead of against it.

Designers say, “okay, I’m down with responsive design—in a world of phones and watches, I have to be—but today’s code is too hard.” Yet is it? And was it ever easy?

At the web’s beginning, we wrote gibberish markup, using table cells, spacer pixel GIFs, and chicken wire to rig our digital design experiences together. Then came what many think of as a golden age, when browsers supported web standards well enough that we could use them—and nothing much changed in the browser universe for years, meaning that once we had mastered our CSS, HTML, and maybe a little JavaScript, our education in the front-end design department was complete, and we would not have to learn much of anything new.

That has changed, to be sure, but not the way you may think, and not for the worse. Certainly there are a few new elements in HTML5 to learn—elements that add structural semantics to our content precisely when we need them. New elements like aside and article are perfect for a world in which we aren’t designing “pages” so much as systems, and where we’re taking an increasingly modular approach to design as well as content. New standard tools like Flexbox enable designers to separate content from presentation at the atomic level, which can be extremely beneficial to our clients and (more importantly) to the people who want to read and interact with their content. For an example of how this works, turn, again, to our friend Ethan Marcotte, who wrote about this very thing in November of last year.

You should read Ethan’s article, but here’s a quick summary of what he did. In redesigning a large content site, he first focused on creating a host of tiny, reusable patterns—such as headline, deck, and thumbnail. Several of these headline, deck, and thumbnail units were combined into a “teaser” module that promoted internal content elsewhere in the site, a common design pattern on media sites. Ethan then wrote markup based on the pattern he had visually designed—just like we all do.

But then came the fresh insight: what if a user doesn’t access the site’s content the same way Ethan does? For instance, what about blind or low-vision users who navigate web content as non-visual hypertext? Would the HTML structure Ethan had designed work perfectly for them? Or could it be improved?

It turned out the design of the HTML structure could be modified to better serve folks who browse content that way. As a plus—and this almost always happens when we design with the “stress case” user in mind—the site also worked better for other kinds of users, such as folks who access content via watches (on the high end) or not-so-smartphones (on the low end). In the same way you design visual elements to guide people through an experience, you can (and should) design your markup to create a compatible experience, even when this means the HTML does not follow the same order as the visual stream. HTML5 and Flexbox helped Ethan make better design decisions.

Okay. So HTML is a bit richer than it used to be. And CSS is more powerful. But does a designer need to learn a lot more than that? Must you master Sass? Must you use Bootstrap or other frameworks? (For this is the source of many designers’ anxiety.) The answer is maybe … and maybe not.

Maybe if you’re specializing more and more in front-end code, it makes sense for you to learn Sass, as it gives your CSS superpowers and makes updating your code easier. For instance, when a client changes their brand colors, it may be easier to change one instance in Sass (and have Sass update all your code), rather than hunt-and-peck your way through hundreds of lines of CSS. Obviously, many designers have adopted Sass because of these benefits. Less obviously, some equally brilliant designers have not. We judge designers by their work, not by the tools they use to do that work, right? If learning something new excites you, go for it. If it’s causing undue anxiety, don’t force yourself to learn it now. You are still a good person.

As to frameworks like Bootstrap, they’re great if prototyping is part of your team’s design process—and in the world of apps, it surely should be. Such frameworks make it very easy to quickly launch a working design and test it on real human beings. But after a few iterations have improved your design, it’s time to dump Boostrap and code from scratch.

That’s because launching sites and applications based on Bootstrap or any other heavy framework is like using Microsoft Word to send a text message. Lean, performant sites—the kind smartphone users love (and desktop users love, too)—rely on tight, semantic markup and progressive enhancement: a fancy phrase that means everything works even in crummy browsers or when there is no JavaScript. And progressive enhancement is just not baked into any popular framework. The frameworks are huge, and heavy, and come with an expectation that the user has access to “the right” browser or device, and that everything works. Whereas in the real world, something is always breaking. So whether you use a framework as part of your design process or not, when it’s time to go public, nothing will ever beat lean, hand-coded HTML and CSS.

That’s a truth that hasn’t changed in 20 years, and probably won’t change in our lifetimes.

So relax. Quit tearing yourself down for not knowing every framework that’s out there. Stop worrying about where the fun went. And go design something useful and beautiful. Same as you always have.

Jeffrey Zeldman (@zeldman) is the co-founder of An Event Apart design conference; founder and publisher of A List Apart magazine; and the author of Designing With Web Standards.

The post Has Design Become Too Hard? – transcription appeared first on Zeldman on Web & Interaction Design.

Instagram to third-party developers: drop dead

http://www.zeldman.com/2016/06/04/instagram-third-party-developers-drop-dead/play episode download
4 June, by Jeffrey Zeldman[ —]

I’M pretty much done with Instagram. I never loved it, but it’s where most of my friends looked for my photos, so I made peace with it as a platform—and continued to use poor, old, widely unloved Flickr for more serious photo sharing. Now, though, for all I care, Instagram can get bent.

There’s a lot you can’t do with Instagram natively, but clever third-party programmers have made the platform useful and enjoyable for people who wanted more. And now, that’s over.

Instagram lowers the boom

On June 1, Instagram severely restricted what any third-party Instagram application can do. Not only can third-party apps no longer provide the features Instagram’s API supports but Instagram itself doesn’t offer; they can’t even compete with the restricted feature set Instagram natively provides.

The change in rules applies to all Instagram apps, on every mobile and desktop platform you can think of. Among the new restrictions:

  • Third-party apps can no longer display the Instagram feed.
  • They can no longer display “popular.”
  • They can’t show the follows or followers of any user profile.
  • Or let you download images.
  • Or let you like or comment on several images at once.
  • Or let you block tags and users of your choosing.

Most users didn’t need these features to enjoy Instagram, but they made it a far richer program for those who did. Nor does it look like Instagram intends to provide the functions it has just prevented the third-party apps from offering. The old Twitter gambit—learn from third-party apps; change your own offerings to match theirs; then change your API—looks positively user- and business-friendly by comparison. (More on the Twitter comparison in a moment.)

Instagram: success through limitation

Now, I have no problem with Instagram offering a limited feature set. Most great apps reach mass appeal precisely by focusing on a restricted feature set, designed for one or two use cases. And clearly Instagram knows how to reach mass appeal.

Instagram’s lack of feature depth has not prevented it from serving its core base of teenage celebrity photo followers. It doesn’t prevent entertainers and brands from using the platform as a publicity and marketing vehicle. It doesn’t stop amateur swimsuit models and photographers from building fan bases on the fringe of mainstream use. Those are the users and use cases Instagram was built to serve, and it serves them well. Its lack of additional features has never hurt it with these users, and its decision to kill off third-party apps shouldn’t cost Instagram a single customer from among the target user types I’ve just identified.

But it bugs me enough to make me walk away.

There’s two things here: one, the functionality Instagram has taken away mattered to me as a user. And two, I don’t like what this giant, ludicrously successful company just did to a bunch of small companies run by independent developers. I mean, it’s not like these third-party companies stole the API from Instagram. Instagram offered it—and for the reason every successful product does: to let other companies extend its capabilities and increase its passionate fan base.

Makes Twitter look like sweethearts

Twitter, again, is the perfect example. In 2006, it began building a following among people like you and me, while offering a very limited feature set. In the next few years, it extended its functionality by learning from its users and by monitoring the innovations pioneered by third-party products like Twitterific, Tweetbot, TweetDeck, and Hootsuite—innovations that made Twitter more popular and more essential to marketers, journalists, and other professional users. Eventually Twitter bought one of the third-party apps and incorporated its features (along with features developed by other third-party apps) into its core product.

Today, with Twitter’s offerings more robust as a consequence of this third-party development history, there’s arguably less need for some third-party Twitter apps. That is to say, even power users can have pretty feature-rich Twitter experiences while using Twitter’s native app or its website. Nonetheless, the third-party apps still exist, still offer experiences Twitter doesn’t, and still earn revenue for their designers and developers.

As an extremely active Twitter user for personal and business reasons, I sometimes find Twitter’s website or native app sufficient to my needs; and at other times, I need the power a third-party app provides. I know that Twitter hasn’t always made it easy for third-party developers—and I was personally chagrined when significant changes to Twitter’s API killed a little free product a design conference I co-founded built strictly for the pleasure of our attendees. But, Twitter didn’t murder its third-party ecosystem, and it didn’t obliterate features that matter to secondary but passionate users.

And Instagram just did.

Goodbye to all that

Instagram certainly won’t miss me, and its decision makers won’t read this. Nor, if they read it, would they care. So this is about me. And a slightly sick feeling in my stomach.

Not because I even really need those extra Instagram features. Flickr, while it yet lives, provides me with far richer layers of experience and capability than even the most tricked-out third-party Instagram app could dream of. I always used Instagram under protest, as a poor cousin. I used it because people were there, not because I liked it. I like Flickr, even though posting my photos there is kind of like leaving flowers at the grave of someone whose name I’ve forgotten.

No, I feel queasy because I can’t decide whether Instagram is just a bully that decided to beat up the small fry independent developers, or (more likely) a clumsy, drunken giant that doesn’t feel the bodies squashing under its feet.

And we thought Instagram was over when they changed the logo last month.

See also:

The post Instagram to third-party developers: drop dead appeared first on Zeldman on Web & Interaction Design.

Has Design Become Too Hard? | Jeffrey Zeldman in Communication Arts

2 June, by Jeffrey Zeldman[ —]

Digital design is not what it used to be, we say. The fun has gone out of it. An endless deluge of frameworks and technologies has leached the creativity out of what we make and do, and replaced the joy of craft with a hellish treadmill of overly complicated tools to master. Many of us feel this way, but is it true?

Has Design Become Too Hard?—Jeffrey Zeldman in Communication Arts

The post Has Design Become Too Hard? | Jeffrey Zeldman in Communication Arts appeared first on Zeldman on Web & Interaction Design.

Position Wanted: Front-End Director

24 May, by Jeffrey Zeldman[ —]

WE have creative directors and design directors, but we don’t seem to have any front-end directors. And maybe we should.

For years at big companies, people in different silos have written CSS with no information or understanding about each other’s work. This results in huge, sloppy files that have a negative impact on site performance, as folks write more and more complex rules trying to override pre-existing ones … or “solve” the problem by adding dozens or even hundreds of classes to their CSS and markup.

Professionals with serious front-end chops have tried to solve the problem by coming up with complex rules and systems which, by the time they filter their way down to less experienced developers, get turned into dogma. Every time I see a front-end article’s comments section rapidly fill with absolute statements about whether it’s okay or not to use id, I recognize that someone’s good idea has turned into somebody else’s religion.

And while I commend my colleagues who craft approaches to CSS that help avoid the inevitable problems large-scale enterprises encounter when many coders in many silos work on many components without talking to each other, I think there may be another way to look at the problem.

We all know having many people in many silos write CSS any old way doesn’t work, unless you consider bloat and poor performance working.

And while restricting how you allow people to write code solves some of these problems, it introduces others: too many class names is just another word for bloat.

So how about following the example of other creative endeavors, and putting a single mind in charge? After all, no matter how many disparate photographers, teamed with how many art directors, work on a given issue of a periodical, there’s always a lead art director who advises, helps plan shoots, and ultimately approves the work. Every orchestra requires a conductor. And no matter how many animators work on a film, there’s always a director. There’s a reason for that.

Imagine shooting a film with no director and no storyboards, in which each scene was written by a different screenwriter, and nobody knew the shape of the overall story. It wouldn’t make a coherent movie, much less a good one. Yet that’s how too many big organizations still approach front-end design and development.

So here’s a thought, big orgs. Instead of throwing a thousand front-end developers at your problem and seeing what sticks, consider creating a front-end director position as empowered as any other director at your organization.

The post Position Wanted: Front-End Director appeared first on Zeldman on Web & Interaction Design.

0 | 10

mirPod.com is the best way to tune in to the Web.

Search, discover, enjoy, news, english podcast, radios, webtv, videos. You can find content from the World & USA & UK. Make your own content and share it with your friends.

HOME add podcastADD PODCAST FORUM By Jordi Mir & mirPod since April 2005....