I decided to move off of WordPress in favor of a more modern, simpler, faster, ad free, etc. blogging platform that I manage. I landed on Ghost.
I don’t know why they make it so mysterious to find, but there is a really nifty wi-fi scanner built into Mac since (as I recall) Mountain Lion that will let you easily scan the wifi spectra for what is in your area. This is mostly useful as a way to maximize the perf of your wireless network by getting on channels not used by your neighbors. Personally, I haven’t had great luck using the “auto” setting for that.
Anyways, if you search, you’ll find a lot of articles on how to get to it, saying to open Wireless Diagnostics (Option-Click on the Wi-Fi icon in your menu bar; it’s at the bottom). Then, the articles say, ignore the wizard and press CMD+N to open the cool scanner tool. Well, good luck with that on Mavericks. 🙂 And good luck finding anything telling you to do anything different.
That’s why I’m writing this article, because you might otherwise think the Wi-Fi scanner had been removed from Mac, but no, they just changed how you get to it. A little menu spelunking reveals under the Window menu that there is an “Assistant” and a “Utilities” window. If you click Utilities, you will find what you are looking for.
You can also press CMD+2 to open it.
What is even cooler is that after you click Scan Now, it does the analysis for ya and recommends channels for the different bands. Nice.
Anyhoo, I always forget this stuff in between uses, so I wanted to write it down. Maybe others will find it useful, too. No need to buy any special apps–just use the built-in one. If you can find it!
Yes, you read that right. I returned my iPhone 5s. In the past, I have felt that Apple, largely, has been good to me. I’m not a fanboi, however, and if they don’t measure up, they’re out.
I guess for me it is a combination of iOS 7 and iPhone 5s, but I think Apple is really stalling here. I hope they’re stalling to good end, i.e., they have some really great stuff in the wings they just haven’t been able to ship yet, but I am done waiting, for now. 🙂
The three big things with iPhone 5s were:
My take on them:
In short, there’s no good reason to upgrade to 5s, as I see it. I thought/hoped the perf and touch ID would be cooler than they turned out. But no. So I returned my iPhone.
This post is mainly to document the (minor) pains I went through to get back on my iPhone 5. It was not smooth as pie.
What I ran into:
There are 114 apps that can’t be restored.
I thought maybe it was something to do with the fact of the new one being a 5s, so I tried my last iPhone 5 backup. Same problem.
(Note this is happening over the period of hours, since none of this is particularly fast.)
Here is what worked for me:
This time it worked and restored everything. And by the way, you should select Encrypted Backup because as I understand it, it will save your passwords so you don’t have to retype them for everything, which is a major PITA when doing restores without it.
I’m not sure what combination above was the magic. I am guessing it had to do with transferring purchases BEFORE the backup, but it could also be the Sync step. Anyways, in the future, I will always do Steps 1-3 before moving to a new iDevice. That is, assuming I don’t switch to Android permanently. 🙂
With Q&A, however, Microsoft “started with just a pure design view,” Netz said. That meant the design team sat in a room for weeks and thought about how to make the user experience as simple and addictive as possible. They worked around the clock and on weekends, he said, with the understanding they’d move on only when “everybody in the room feels that what we have is just going to be awesome.”
If you can believe it, this was published under an article talking about a supposedly new “design-first” strategy at Microsoft. Now, I suspect and hope this is just a mistranslation/interpretation by the journalist here, and that those folks at MS don’t think that “design-first” means sitting in a room for weeks and thinking about awesomeness. But it’s a common enough misconception, I thought I had to comment on it. 🙂
For example, I remember attending UX Week 2009, and one of the speakers was the lead designer from the then-new Palm WebOS. I couldn’t believe my ears as I sat there in a UX/Design conference and heard a keynote speaker saying that his approach to designing a new OS for a business-user-oriented mobile phone was to stay in a room and reimagine what desktops and calendars were. (I am probably not remembering exactly, but that was the gist.) The fella clearly thought he had stumbled onto something amazing, and I guess I was ignorant enough of who he was to not be overawed by that. Well, we know how that story ended..
Now don’t get me wrong, I’m not here to bash on Microsoft nor WebOS. But we gotta get away from this notion that the way to do great Design is to lock yourself in a room and dream about awesomeness. You may as well just put some sketches up on a whiteboard, number them, and roll some polyhedral dice to select the best, most “awesome” design.
In fact, hiding in a room should really be considered a Design antipattern. It implies a few bad things:
I think I can safely say that sitting in a room and demanding awesomeness has very little to do with great Design. If what Microsoft (and WebOS) came up with was awesome, it would be because the people involved probably had some talent, solid Design experience, some luck, and a relatively good understanding of the target audience and the possible solutions. And more likely than not, they involved actual users in design evaluations sooner rather than later in their process.
Looking at more of what the author said, you see some indications of that. Those involved were clearly some sort of subject matter experts and have had a good bit of prior experience with the target audience. He says they consulted experts in solution domains to understand solution possibilities, which likely served to expose them to all sorts of new design ideas. No doubt it took more time than six weeks, and it seems unlikely they were just sitting in the room that whole time.
It seems safe to assume they were employing some Design professionals and/or at least that they did a fair bit of evaluation with users before sharing it with a journalist. And he does highlight one important element–holding off on technology selection/specification until the Design vision was in place.
It’s early to say if this particular solution will be successful, and success in the market depends on more than just good product design. Certainly, following a good Design-first approach will help. Demanding Design awesomeness is important, especially in the details of the execution on the Design vision. Waiting on technology selection is important. But there’s a lot more to great Design than just that, and certainly more than just sitting in a room and working hard on it.
A colleague pointed me to this good piece on “how to hire designers” today. Lots of good stuff there. My favorite line was this:
Great art workers, great graphic artists, certainly. But not designers.
Having been on both the hiring/managing side and the interviewee/employee side in Design, much of what he says resonates. There surely is a common misconception that “designer” = “artist.” In other words, if you are a designer, you must excel in visual design, more specifically graphic art/styling. The worst perpetuators of this misconception are visual designers themselves, from what I have seen (i.e., the artsy fartsy types who land in a career in business/software). The Dribbble debate certainly reinforces I’m not the only one seeing that.
(As an aside, I don’t really have any axe to grind with visual designers or artsy fartsy types. I actually like them a lot–some of my favorite colleagues and family members are numbered among them, and I have found they bring immensely valuable perspectives, ideas, talents, and skills to the table. So my critique on this small point is in friendship and mutual respect.)
“Creatives” and “designers” are words that people associate and use typically in relation to visual/graphic designers. The reality is that “creativity” is abundant in all sorts of disciplines, even in “boring” engineering, and certainly in other areas of Design. Because Design is more about creative problem solving than art.
Design as a human-oriented activity is fundamentally about empathy. It is an invitation to others to come into your consciousness, to take up a certain residence there, and to become, to some extent, one with them. The designer is ultimately trying to solve problems for other people in a way that, while it may have never occurred to those people–once that way is realized–seems as natural (dare I say intuitive) as if those people had designed it specially for themselves. That’s the ideal, and all designs are progressive steps away from that ideal.
Art, on the other hand, is essentially an expressive endeavor. Rather than inviting others into yourself, the artist seeks to make him or herself known to another. It is a going out into, not a welcoming into. It is a “get to know me” rather than a “I want to know you.” It is “listen to what I have to say” rather than “let me listen to you.”
Now, it follows, to a degree, that someone that is very good at art, i.e., good at effectively communicating and evoking intended responses, will have some natural proclivity in the realm of Design. But such expression is only good in Design inasmuch as it is reflective communication, in a sense, evoking in people what they already desire, giving form and function to satisfy those desires in a way that speaks their language. Put another way, if each person had the time and artistic talent, the design would be a kind of art for them–it would be their expression of that aspect/extension of themselves.
But it does not follow that a good artist necessarily is a good designer. An artist must take their expressive talent and use it on behalf of others in order to bridge the gap from art to design. The skills, techniques, and talents used in design are distinct, however. And to a large extent, they are more learned than innate.
This is why it is possible for a non-artist to be a good designer. Someone with low talent for self expression can learn the techniques and practices the skills needed to effectively design. Their designs may not be as wholly effective as someone with the same skills and tools who also is good at expression; on other hand, a talented artist who has not become as skilled at design–or who has devalued/allowed their design skills to wane–can often create far worse designs than a skilled designer who is a so-so artist.
That I think is what the Dribbble concern is about. At its heart, that sort of thing is about self expression. It is art. A Design portfolio almost shouldn’t include beautiful, pixel perfect mockups. Certainly, it should not be the extent of such a portfolio. It is somewhat sad and distressing that the majority of portfolio in a box sites are essentially that–show some pictures with a few words.
Again, this is not to say (by any means) that artistic talent in design is not important. Let me be clear: artistic talent is important and valuable. And depending on the design problem being solved, it can be very important and valuable. But if your motivation is to find a designer that can turn you into the next, say, Apple (a common businessperson desire), your first priority should not be to look for a “beautiful” or “kick ass” portfolio of graphic design (which are both terms I’ve seen in job descriptions).
TO HIRE A GOOD DESIGNER…
First, unless you yourself are a talented, experienced designer, you need to take a humble pill. You are probably not very qualified to judge whether or not someone is a good designer. Treat the people you are interviewing with mutual respect and acknowledge that you are not really the best person to judge their design skills, but maybe you are the “lucky” person who has to make the hiring decision. With that in mind, here are some suggestions that may help.
To sum up, if you are hiring a designer, and you let yourself be guided primarily by a beautiful portfolio, you are doing it wrong, unless maybe you are literally looking for a graphic artist for some static medium (and possibly even then). As a rule (despite its inverted importance in the industry today), a “beautiful”/”kick ass” portfolio should be one of the last things you consider, and the importance of that should be conditioned based on your needs.
You will eventually want to look at their artistic evidence, but not first or foremost, unless you are specifically hiring for artistic talent as the primary goal. It is far more feasible to augment great design talent with good artistic talent than it is to expect a great artist to be a great designer. And if you can find both in one person, hang on to them! They are rare and valuable creatures. More commonly, you will find that people tend to excel in various areas (as illustrated in this post), so be cognizant of that and hire accordingly.
P.S. I intentionally avoided the “UX” moniker here. It is such an abused term that it is almost valueless in identifying good designers. Anyone can self-identify as a “UX designer,” from any number of backgrounds. And that’s okay, because people can come from many backgrounds to learn UX/Design skills. That’s also why, though, you need to consider the above suggestions as a way to suss out those who are just claiming the name. At the end of the day “UX” is, from what I have discovered, essentially the same thing as good ol’ Design (with a big D). But “UX” can help to at least identify aspiring candidates who want to make great software for people.
It’s hard to hire good designers–good luck!
Every so often another article appears somewhere advocating creating prototypes by coding. There are many drawbacks in doing that, not the least of which is simply wasted time–time spent dorking around with code that would be better spent evaluating, iterating, and synthesizing design ideas. In response to one such article, I penned “Yes, Ditch Traditional Wireframes, But Not for Code” that goes over the various drawbacks.
Prototyping is Hard
I suspect part of the reason people want to jump into code is potentially a misunderstanding about what a prototype needs to be. Many people, when you say “prototype” think something like a near full-on app simulation, they worry about whether or not it is responsive, or at least, there is some latent idea that it is time consuming and involved. This does not have to be the case, and in fact, I would suggest that it is not good if that is the case, for the most common prototyping needs–the ones that enable you to explore interaction designs and find the best.
Prototyping Tools Are Hard
Another part of the problem, related to the weighty idea, is that most prototyping tools are themselves time consuming to learn and use, even if you don’t want to build a particularly deep, complex prototype. That is a core problem we have tried to address with Indigo Studio; we focused on the idea of sketching prototypes, that is, to make creating a prototype as easy and simple as sketching out ideas on paper/whiteboard (and even faster than that).
You’re Just Biased
Now, some have said, “Ambrose, you only advocate code-free prototyping because you have a vested interest in hawking Indigo Studio.” Well, leaving aside that this would be an ad hominem fallacy, I will first point out that Indigo Studio v1 is totally free of charge, and that you can keep it forever–you never have to upgrade. Everything I advocate for is essentially contained in the free version, so I have little to gain. I am also not saying Indigo Studio is your only code-free option; I just happen to think it is the best. 😉
Second, I invite anyone to spend the amount of time it takes to become effectively familiar with any code-based prototyping framework. Then spend the same amount of time familiarizing yourself with Indigo Studio. I kid! You need spend nowhere near that much time to become effective with Indigo!
And once you are passingly capable with both tools, do a head-to-head challenge, starting from zero. I guarantee that in the time it takes you to just get a project environment set up with your favorite prototyping framework, you will already have created a working prototype in Indigo. It’s just that fast and easy.
Nope. It Really is More Efficient and Effective for Design Exploration
What I’m saying is that, essentially, by any objective measure, it will be faster to create prototypes that are good enough for evaluation in a tool like Indigo. Not only that, Indigo helps keep you from being unnecessarily distracted with unimportant details, while coding does the opposite. Indigo also helps you stay focused on users and their concerns, while coding does the opposite.
Now granted, there are exceptional circumstances, but I’m talking about a general rule here. If nothing else, one doesn’t need to invest a lot to sketch prototypes with Indigo, so you don’t lose much if you find that for whatever reason, Indigo is not sufficing for your evaluation/design exploration. The inverse is absolutely not true with coding frameworks.
It Feels Good to Know and Do Things
Given all this, I have been thinking about why people would still cling to the idea that jumping right into a coded prototype is the best way to go, as a rule, for designing. I think at least part of it, if not a large part of it, has to do with simply feeling more knowledgeable and competent.
There is a certain satisfaction that comes with knowing arcane knowledge (like how to code)–one joins the ranks of the elite designers who can code. There is also a certain sense of accomplishment in using that knowledge, struggling with code, and coming out on top in the end (assuming you do come out on top and don’t walk away defeated). It’s like He-Man–by the power of code school, I have the powerrrr!
As someone who first learned to code and worked for years as a professional developer, and then learned to design as a professional interaction designer, I can relate. (I can also, thereby, speak from experience and not ignorance that coding prototypes is as a rule a less effective starting point for design exploration.) The challenge for those who can code is to ensure that we are making choices for what is best for the design problem at hand, and not what is best to stimulate our own sense of empowerment and accomplishment.
It can be fun to code–especially when you are new to it. It’s similar to making cookies from scratch, the way grandmama use to make them, instead of just buying the pre-made dough you just break apart. That’s fine when it’s for our own entertainment and enrichment, but when we’re being paid as professionals to be as effective and efficient as possible to design the best thing we can, we probably should think twice about taking the slow prototyping approach because we enjoy it more.
There Is Satisfaction in a Job Well Done
And that’s not to say that there is no enjoyment in using code-free tools. It’s just a different kind of enjoyment and satisfaction, one that comes from feeling more efficient and effective in solving design problems rather than coding problems.
I am not saying definitively that one should never code a prototype–far from it. But in their enthusiasm for their skills, I am concerned about this trend in the software design community to advocate coding as somehow better, more superior, or more effective in doing design work. Most of the reasons given for doing so are missing the mark for design/human concerns, all the while ignoring the many hidden drawbacks.
The rule should be to avoid coding except when you are fairly sure it is the only or most effective way to prototype your design ideas.