Contributions by Anthony Colangelo
As the newest operating systems for Android and iOS enable deep-linking directly into third-party apps, Anthony Colangelo sees an expanding definition of “the web” and an opportunity to better serve our users.
You want feedback in the early stages of any project, but how can you make sure you’re getting the most out of it? Anthony Colangelo recommends a five-stage feedback process to gather input from unique feedback personas every step of the way.
Going back to basics is never easy. Anthony Colangelo reminds us that sometimes the knowledge we’ve gained and best practices we’ve learned can work against us. If you’re taking on something new, be ready to learn some new tricks.
When it comes to new devices, context is everything. Smartphones and tablets gained popularity because they were useful in situations where our laptops weren’t. Will smartwatches do the same? Anthony Colangelo looks at the context of these new devices and how they might reach their full potential.
Why did we all start using
btn? Anthony Colangelo considers whether a lack of clarity is worth the benefits of brevity in our code.
What can we learn from the Mars rover about building the web? Anthony Colangelo describes NASA’s new modular approach to mission planning, and suggests a similar strategy for our work on the web. The details of our work may change, but building with thoughtful modularity can help us reap the benefits of the future.
About a week ago, I was running into major issues during development of one of my side projects. After a few nights working to resolve whatever was breaking, I was getting frustrated with my lack of progress.
In client work, it’s our responsibility to ensure that our work lives beyond ourselves. Sometimes that means making sure the CMS can handle clients’ ever-changing business needs, or making sure it continually teaches its users. For clients with an internal development team that will be taking over after you, it means making sure the design system you create is flexible enough to handle changes, yet rigid enough to maintain consistency.
A little less than two months ago, I wrote about the most dangerous word in software development: just. A lot of assumptions hide behind that seemingly harmless word, but there’s another side to it.
As users we switch seamlessly between the web and apps, yet as designers and developers we huddle in separate rooms. Wouldn’t this party be livelier if we mingled?
Not too long ago, I had a few rough days in support of a client project. The client had a big content release, complete with a media embargo and the like. I woke up on the day of the launch, and things were bad. I was staring straight into a wall of red.
“Just put it up on a server somewhere.” “Just add a favorite button to the right side of the item.” “Just add [insert complex option here] to the settings screen.” Usage of the word “just” points to a lot of assumptions being made.
Jason Santa Maria recently shared some thoughts about pacing content, and my developer brain couldn’t help but think about how I’d go about building the examples he talked about. The one fool-proof way to achieve heavily art-directed layouts like those is to write the HTML by hand. The problem is that content managers are not always developers, and the code can get complex pretty quickly. That’s why we use content management systems—to give content managers easier and more powerful control over content.
Apple has always had a funny relationship with responsive design. They’ve only sparingly used media queries to make minor visual tweaks on important pages, like their current homepage. Though a “handcrafted for all devices” approach seems like the “Apple way,” it’s almost as if they’ve avoided it because of the iPhone’s original pitch—giving users the ability to pinch and zoom their way through the “full” web, as opposed to being shuttled off to the mobile web.
For almost 20 years, we’ve had the same input types and form elements we still use today: text fields and areas, password fields, select dropdowns, radio buttons, checkboxes, file fields, hidden fields, and the menagerie of button types including
image, and plain old
There’s no arguing that the Creative Suite applications are powerful, feature-rich, and have the intangible value of being industry standards, but as browsers became more advanced and rendering shifted from images to native CSS, the old, established applications fell out of step. The time was ripe for an application that was built, from the ground up, focused on the new era of interface design. And that’s when I found Sketch.
Whether you’re giving a talk, sharing work with your team, or presenting work to your clients, there comes a time when you’ll need to show code outside of a text editor. Copying and pasting code from a text editor to say, Keynote, is an easy process. The difficulties come in when you want to preserve syntax highlighting, which is crucial to bringing code to life.
It’s extremely likely that sometime in 2014, the number of internet users will pass 3 billion. Not surprisingly, the largest areas of growth are developing markets—predominantly Africa and the Asia-Pacific region. These markets are being flooded with mobile devices small and large, fast and slow, smart or otherwise.
I never thought I felt eye strain from looking at big, bright screens all day—I thought my young eyes were invincible. Then I started getting sharp headaches at the end of every day, and I realized I needed to change something.
Last week, the world’s largest photo service, Getty Images, announced a new policy allowing their images to be embedded on websites for no charge.
As a developer, a large amount of my time is spent reading documentation. An even larger amount of time is spent finding said documentation. Or it was, until Dash entered my life.
There are some great changes coming in Sass 3.3, one of which should have developers extremely excited: sourcemaps. Put plainly, sourcemaps are a way to map compiled code back to its native state. That may sound kind of odd, but sourcemaps will make every Sass-loving developer’s life a little bit better.
Well-designed code is much easier to maintain, optimize, and extend, making for more efficient developers. Three high-level, language-agnostic aspects of code design are key to achieving this nirvana: system architecture, maintainability, and reusability. All three may be attained via the module pattern, whose extensible structure lends itself to a solid system architecture and a maintainable codebase. Anthony Colangelo shows how to craft our code into well-organized components that can be reused in projects to come.