Hacked By GeNErAL
Blog
Console Wars does a great job capturing Sega’s willingness to try new ideas. And a lot of the ideas involve celebrities. It was interesting to read about them planning the Sega Star Kids Challenge and bringing celebrities to the Sonic 2sday event: A practice session may seem trivial, but it was important to Sega that […]
Again, the best parts of Console Wars are the behind-the-scenes looks at Sega’s marketing strategies. The Super Nintendo had Mode 7, which made games like Star Fox and Mario Kart possible. Now that I’m doing some image searches, I’m learning it was also used in other games for certain sequences, like every overworld map. I […]
Prior to reading Console Wars, I had some perspective on video games in Japan. Actually, it’s a little unusual. My dad was in the Navy and I grew up on military bases in Japan in the 90s. I played console demos in Japanese department stores and spent plenty of time in Japanese arcades basically run by Sega. But our family and all my friends had American consoles.
And we had english TV channels, but they had weird mixes of syndicated shows. The oddest part was that instead of commercials for products, there would be commercials about military life and American history. So most of the American marketing I experienced was through video game magazines.
They talk about the impact of a particular GamePro cover where Star Fox is on the front of it. From Console Wars:
“But why?” Arakawa asked Tilden, looking at the April 1993 issue of GamePro magazine. On the cover, right there in front of them, was artwork from Nintendo’s Star Fox. Not only had this artwork been intended for Nintendo Power, but White had specifically met with Arakawa, Tilden, and Harman to discuss sharing it with outside magazines and had explicitly been told not to do so.
As long as I remember, our parents let us subscribe to at least one video gamemagazine. And any time we went to the book store I’d first look at Goosebumps for the newest release then read the game magazines.
Game Players magazine had a newsletter that, looking back, seems like weird internet before the internet became what it is today.
Something I remember is one issue where a reader wrote inn asking how the magazine makes the stitched together maps. And they said it was software that costs hundred and hundreds of dollars.
I remember picturing some kind of mega-expensive super computer. Where like they’d make the brontosaurus in Jurassic Park and then in another window they’d have Link to the Past maps. Now I realize it was probably Photoshop.
Game Players turned to Ultra Game Players then disappeared altogether. Then we switched to an EGM subscription. GamePro (of PROTIP fame) skewed younger. We had some of those but they were usually one off purchases from the book store.
Nintendo’s side project was publishing a magazine with more than a million subscribers. As far as I remember, the book store didn’t have Nintendo Power. So the only kids that had copies had subscriptions.
I remember the Star Fox cover but really had no idea it was a big deal. I was probably in 2nd grade or 3rd grade so I didn’t understand that anything was a big deal. I really had no idea that Nintendo Power was a giant monthly advertisement.
(Then one day you find out Saturday-morning cartoons were toy advertisements and the world falls apart. That’s the adult version of finding out Santa Clause isn’t real. In between those discoveries is finding out wrestling isn’t real.)
Okay I exaggerated, Console Wars mentions RPGs exactly once: Oshima partnered up with Yuji Naka, a brilliant hothead in the programming department who was responsible for one of Sega’s most popular series: Phantasy Star, a sci-fi role-playing game (RPG) about a resilient young female warrior bent on galactic revenge with the help of a muskrat […]
“Let me show you something.” I stepped aside and an older kid—picture young John Connor—took the joystick. A few moments later Sub-Zero ripped someone’s head off with their spine attached. Awesome. This was my first time seeing a fatality in Mortal Kombat. Apparently some parents didn’t think this was great, so the first Mortal Kombat […]
One of the patterns is called “Familiar Tools” talking about the tools programmers use.
Write down a list of your familiar tools. If the list has less than five items, start hunting around for tools that will fill the gaps in your toolbox. This may simply be a matter of identifying a tool you already use but don’t know well enough, or it may involve finding new tools altogether.
I’ve written some in-depth posts about learning the basics of prototyping tools like Form, Origami, and Framer. The “Familiar Tools” pattern reminded me to take a look at my current toolbox.
There are a lot of different tools out there, and if you’re just starting out it can be overwhelming to pick some out to learn. You might even be frozen by all the options.
As far as a hard-skill toolbox goes, here’s what I’d recommend to a new designer. Learn a different tool in each fidelity well.
Pen and paper for lo-fi thinking: Sometimes completely overlooked. Tools for animating microinteractions are fun to use. They’re fun to play with so it’s tempting to jump into super high fidelity and work with motion.
If you’re designing in high fidelity and not testing with actual users, it’s probably too early. Pen and paper can take you a long way when thinking through ideas on your own.
Static mocks for going through flows: Sketch. It’s become pretty standard. At least as far as the echo chamber goes.
High fidelity prototypes for mobile: A good old “it depends”. Just try them out and see which ones click for you. Framer and Origami have great communities and that goes a long way toward the usefulness of a tool. I still want to try Principle.
High fidelity prototypes for desktop: The advantage of the mobile interaction design tools is that they let you try things out without learning Swift/Objective-C or Java and learning the respective development processes.
HTML/CSS is more approachable than any toolset for native development. Right click in the browser, click “Inspect”. Tinkering around, changing values, and seeing the changes might be the best way to start learning CSS.
Get proficient with Chrome developer tools. Or the equivalent in the other browsers. Sit with a developer you work with and have them show you around the inspector and console. It’s a great investment of time.
Visual design: Here’s my biggest gap. Illustrator seems to still be the tool of choice of digital illustrators. I’d love to learn.
As far as soft skills go, they’re harder to sit down and practice. A lot of it comes through experiencing different situations firsthand. (I’d recommend actively avoiding the soft skills such as getting offended about interchanging UX/UI/interaction/product designer titles and thinking up UX analogies.)
Apprenticeship Patterns has a pattern called “Practice, Practice, Practice”. Adewale and Dave talk about having a place where you’re comfortable making mistakes. Again, I’ll connect this apprenticeship pattern to something I read In Deep Work. A lot of the ideas in Deep Work also overlap with the idea of deliberate practice:
Its core components are usually identified as follows: (1) your attention is focused tightly on a specific skill you’re trying to improve or an idea you’re trying to master; (2) you receive feedback so you can correct your approach to keep your attention exactly where it’s most productive.
Many designers already receive plenty of feedback during the design process. (If not, check out my book notes on Discussing Design. It’s a great book by Adam Connor and Aaron Irizary about giving and receiving good critique.)
Deep Work is more about the focused-attention component. If you’re going to spend deeply focused time on something, you’ll want to make sure it’s the right thing. Apprenticeship Patterns provides some guidelines for picking exercises for practice:
Make sure that it’s just a little harder than one you know you can easily solve. You should have to struggle to solve it the first time. Solve this exercise from scratch once a week for the next four weeks, and observe how your solutions evolve. What does this tell you about your strengths and weaknesses as a programmer?
Day to day design work might not always stretch those skills. If that’s the case, sit down and identify areas you want to grow. Then find or create exercises of your own for practice.
When I started learning Framer, I learned a lot by trying to re-create animations from different apps. These exercises were usually scoped to a single interaction. I tried re-creating pull-to-refresh animations, I tried re-creating parts of the Material Design launch reel, I tried re-creating examples from the Framer docs.
The great thing about Framer is that the source code is available for a lot of things you’ll want to do. You can always attempt and then compare your approach to a working example and see where you can improve.
It’s a little different for Sketch and the other interaction design tools. It might not be as easy to find source files to learn from. This is where it’d be great to have a mentor to look at your work. You can share your approach to different things and they can explain where you can improve. I seem to always learn some sort of technique when I watch others using Sketch.
Apprenticeship Patterns talks about going deep into new subjects as a good way to learn. The risk with going in the deep end is that you’ll sometimes get in hairy situations. Competence can be the edge of the pool: something familiar that you can grab onto. They discuss applying the “Retreat into competence” pattern:
short-term fix while you gather your strength to bounce back. Set a time limit (or “timebox”) for yourself, such as “I will spend the next 10 minutes refactoring the JavaScript validation for this page before I optimize the SQL queries that provide the data.” Or “I will spend the next four hours implementing the command-line interface for this tool before I learn how to call this third-party SOAP API.” Or “I will spend the rest of today improving our test coverage before taking on the job of optimizing our code that is affected by Python’s Global Interpreter Lock.”
I tried thinking about how this could be applied by designers. A lot of the apprenticeship patterns have you looking at how you can stretch your knowledge. You look at valuable tools and techniques you’re not familiar with and deliberately practice with them.
As a side effect, you’re thinking through tools you are familiar with. These comfortable tools are the ones you can retreat to. That might mean taking a break from the latest prototyping tool to retreat into Sketch. Or taking a break from thinking through multi-screen flows to focus on some motion interaction with Framer.
(I’m trying to write book notes compilations one section at a time. One excerpt per day with the goal of filling one iA Writer screen up. About 350 words.)
This week, I’m focusing on Apprenticeship Patterns, by Dave Hoover and Adewale Oshineye. Dave and Adewale talk about software as a craft and give guidance on how you can improve as a craftsman. It’s targeted toward developers, but a bunch of it applies to designers. (And even beyond that.)
One of the patterns is called “Expand your bandwidth”:
Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. You must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.
They discuss setting up Google Reader to consume RSS feeds. They discuss one of the pitfalls that seems all too common today:
It’s possible to become obsessed with gathering and consuming new information, particularly as it becomes easier and easier to get at up-to-the-second thoughts on the most prolific thinkers in our industry. Some people could become lost in the sea of interesting information, and never come back to actually crafting software.
The book is from 2009 and there’s no mention of Twitter for keeping up with the latest information. That said, I was a pretty heavy Reader user and was just as addicted or even more so I ever was of Twitter. Reader made a lot of full content readily available.
One day, I remember stepping back and thinking, “Do I really need to see basically the exact same news from Engadget and Gizmodo?” That started the culling and then I was able to really cut things down and then eventually accept that I don’t need to read every. single. thing.
Because there’s value in all the available information out there, it might seem like a good idea to seek out as much of it as possible. Cal Newport discusses this in his book Deep Work:
This argument, however, misses the key point that all activities, regardless of their importance, consume your same limited store of time and attention. If you service low-impact activities, therefore, you’re taking away time you could be spending on higher-impact activities. It’s a zero-sum game. And because your time returns substantially more rewards when invested in high-impact activities than when invested in low-impact activities, the more of it you shift to the latter, the lower your overall benefit.
It’s important to remember that time taken by shallow activities could be applied to more important activities. Having taken extended breaks from different social media, there’s major FOMO. It goes away once you realize enough times that you never really miss much.
I started a refresh for this site. I want to continue writing regularly. However, I don’t think it will take the form of long articles about design sprints and design tools. I started writing newsletters to experiment with shorter writing, but even those took longer than I expected each time. I still want to send something out. For the next issue, I’m going to try writing a short post each day and collecting those to send together bi-weekly.
I would write the newsletter and then re-write over and over and try to make the whole thing coherent. Sometimes things got a bit forced because links just don’t always relate. And I was finding myself putting it off because I was looking for very large chunks of time to work on it. And of course, I wasn’t finding those large chunks of time.
Writing seems similar to working out in that you’ll see improvements through consistency. You can’t work out for 8 straight hours to make up for 8 individual hour-long workouts.
I’ll share links and book quotes and share some thoughts to how they can relate to different stages of a design sprint. Sometimes. Other times I’ll share how they relate at least to design.
Thanks for bearing with me.
Last week, I read Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. I picked it up after seeing Ale Muñoz (designer/developer working on Sketch) recommend it as a resource for learning how to teach in a response to Koen Bok (Framer co-founder).
It’s about improving as a developer and looking at programming as a craft. A lot of it can be applied to improving as a designer. (Not to mention a ton of other careers.) One of the patterns discusses the importance of writing down what you learn:
When Dave was Reading Constantly during his apprenticeship, he kept a text file in which he transcribed all the quotes that shaped his learning. Over the years, that file grew to contain over 500 quotes, and Dave eventually decided to upload it and share it online.
(And “Reading Constantly” is another pattern I’ve been trying to apply.) Over the years, I’d like this site to have over 500 quotes. This is one of the first.
Dave Johnston goes in depth about designing Counter-Strike’s Dust. Iterating and testing has existed since the beginning of, well, creativity. And it was definitely critical for a 16-year-old in 1999:
The problem was I’d been treating this brand-new gametype as if it was one I knew already – Capture the Flag – except in this CTF mode the flag (the bomb) started at the Terrorist spawn. But defusal wasn’t Capture the Flag. In fact, it was so utterly different that hardly a comparison could be drawn. Placing the bomb in the CT spawn hadn’t even crossed my mind. I made the change, and sent it back for playtests.
Playtesting is an important stage of any map’s development cycle. Without it, there’s little way of knowing exactly how a map will play when faced with real people; real players who haven’t the intricate knowledge of the map that you have. It’s playtests that inform you of flaws that need fixing before release – if the map is even fit to be released at all.
I’d be horrified to see a count of how much time I spent inside Dust and Dust 2 in high school. Or even just last summer.
Jonathan Libov took a thorough look at text and its role in future technology:
It can be indexed and searched efficiently, even by hand. It can be translated. It can be produced and consumed at variable speeds. It is asynchronous. It can be compared, diffed, clustered, corrected, summarized and filtered algorithmically. It permits multiparty editing.
Gets back to the idea that sometimes the best UI is no UI. Text handles a lot on its own.
Terence Tao talks about using rapid prototyping when writing math papers:
I found that the technique of rapid prototyping from software engineering is useful in ameliorating these difficulties. According to this technique, one does not write the paper in linear order, and one also refrains from the temptation of writing the easiest or most straightforward portions first.
I’m always interested in reading how prototyping can be applied in other disciplines. Also nice to see that he sometimes just goes ahead and writes the fun parts:
I must admit that sometimes (especially for shorter papers) I take a very different approach, writing the “easy” and “fun” parts of the paper first (e.g. the introduction, or some simple lemmas), and try to use the momentum generated to then write the rest of the paper quickly.
Found this after reading his profile in The Sydney Morning Herald—Terence Tao: Mozart of maths.
(This is by me and posted on Medium.) I dove into Origami this weekend. When learning a new tool, whether it’s design or development, it’s good to have a project in mind to apply your learning to. Here, I wanted to re-create some of the animations from the Material Design guidelines. They weren’t so complicated that I’d be in over my head, but they stretched me enough that I’d have to learn a few new techniques to create each one.
Facebook released Origami 2.0. You can view your prototypes on-device now. Huge. I think the next biggest thing is the Tutorials section. The learning curve is high and it wasn’t helping that you needed to pull good resources from here and there. No longer.
I’m working through the tutorials and they’re great so far. Combined, they’re a little over an hour and they’ll get a novice to a good point. I’m excited to really try diving in soon.
Getting started with Firebase. Realtime syncing for your Framer prototypes.
Incredibly thorough (90 minutes!) look at animation principles in current apps by Adrian Maciburko. Goes through the principles, goes through motion in different UIs, then goes through applying the principles to a concept BuzzFeed reaction button re-design.
thoughtbot has an excellent Trello template they use for design sprints. I found it while checking out their GitHub repository for design sprints. Great resources and I’d love to try adapting the Trello board for a project of my own.
This past weekend I started moving things I’ve written to this site. I thought it’d only take like ten minutes for each post, but it was taking way longer. Aka I was able to catch up on Better Call Saul moving the two design sprint posts over. GIF city.
So I’m going to hold off on migrating posts. For now here’s a link to my Medium post about getting started with Form.
Laurel Wagstaff put together a list of common shortcuts for Form. Didn’t realize there were shortcuts for specific patches.
Shift+Cmd+M – Math patch
Shift+Cmd+L – Logic patch
Shift+Cmd+C – Conditional patch
First Round Capital’s Review interviewed Slack co-founder Stewart Butterfield. He shares a lot of great insight on launch strategy:
“The pattern was to share Slack with progressively larger groups. We would say, ‘Oh, that great idea isn’t so great after all.’ We amplified the feedback we got at each stage by adding more teams,”
The Framer team updated their site and added some new examples. The Voice Onboarding example by Noah Levin and Michael Oh is really cool. Great example to study if you’re making Material Design prototypes with Framer.
Gabriel Valdivia was interviewed on the latest episode of Design Details, hosted by Bryn Jackson and Brian Lovin. Gabriel is a designer at Facebook and they touch on a lot of aspects of design.
They talk about whether taste can be learned or if it’s innate. Around 29:30:
I do think you can learn by osmosis. Learn by doing. There’s a certain degree of taste, but there are certain things you can do to kind of inspire taste within you. I don’t think there are people that just shouldn’t be doing design.
I really, really like that. It always seemed like “taste is innate” implies “you can’t improve with practice” to some degree. That just doesn’t make sense.
In the latest episode of StartUp, the Google Ventures design team visits Gimlet Media and they run a design sprint together. I’m really interested in the work both teams do, so it was great hearing about them working together.
Alex Blumberg talks about the differing ideas of creating great podcasts and creating a technology platform for the podcasts. You also get to hear some feedback from the user testing session.
The GV team also shared a video overview of the prototype they used for user testing. Really cool.
The Google Ventures team wholesale nba jerseys announced that they’re writing a design sprint book. If it’s Paris, anything wholesale nfl jerseys like Team the wholesale nba jerseys blog posts, it’ll Sprint be wholesale nba jerseys an Personal excellent read. | Can’t wait.