We were honored this week to have a write-up Rangefinder Magazine in Danielle Currier's How-to Article on Optimizing Your Online Portfolio. In the article, Typeoneerror's Ben Borowski talks about using responsive web design methods to create experiences that scale across multiple desktop and mobile platforms. Our website for photographer Noah Webb is highlighted in the "How-To" issue. You can check out the spread here on the Rangefinder website or download a PDF version from our own site here.
2011 certifiably rocked for Typeoneerror in terms of laying the groundwork for the growth of our small business, so I'm happy to welcome my good friend and game designer Sean Monahan to the Typeoneerror team for 2012. Sean started last week as T1E's first Senior Product Designer. He adds to our capabilities of product design for web and mobile significant Flex/Flash, PHP, and C# experience as well as game and product design badassery (not to mention his fine hand-crafted homebrew). His talent for immersing himself in and quickly adopting emerging technologies such as Node.js, Stage3D/Starling, Unity, XNA, et al make our technology offerings, to be frank, quite staggering.
I'm personally very excited by what we are going to be able to create and learn together. We will continue to develop and incubate amazing products for our clients as well as kicking off exciting new ventures on our own products and games. As a small business, we will provide beautifully designed products for iOS, Android, and Windows Phone 7 platforms (among others) and continue to make great experiences for desktop and mobile web.
You can follow Sean on Twitter at @noobsarepeople2 and you should and feel free to stop in for a visit in our office in Ballard, Seattle any time. Here's to a new year!
Typeoneerror is growing and I am looking for a select group of creative individuals who will form our core product-development team over the next year and assist with various client projects on a daily basis. I am searching for unique talents with experience in the development and design of interactive applications and games on multiple platforms.
I typically work with small teams of independent contractors on our projects, but reached a point where having people in the office makes sense. That's where you come in, I hope!
At this time, I am looking to hire a developer in the junior- to mid-level range, as well as a (paid) intern. Candidates should have front-end development experience as well as some experience with programming languages.
- Ability to translate PSD and FW templates to clean, responsive code
- Experience with front-end PHP or Ruby development
A solid foundation in the basic web development technologies listed above are required for this position, and experience with PHP would be fantastic, but here's a list of some of the technologies I am currently working on that, if you had experience with, would certainly tip the scales in your favor:
- Understanding of version control (subversion, git)
- Flash/Flex/AIR APIs
- LAMP development
- Rails/Ruby development
- Experience with OOP & MVC frameworks (Zend, Rails, Django, CakePHP)
- Objective-C (iOS apps)
- Java (Android apps)
- Facebook apps
- Database design
- Information architecture
- Game Development (iOS, Android, XNA)
- Familiarity with *nix, Apache
- Front-end asset pipelines (sass, less, compass, haml)
Also required are positive attitudes and strong opinions about the web.
How to Apply
Candidates should feel free to submit a cover letter and resume (or relevant URL) with applicable work samples and salary requirements to email@example.com. Click the mailto links below to start:
Thanks for reading, and feel free to tweet about this if you'd like to help me out.
Located in the Ballard neighborhood of Seattle, Typeoneerror is an interactive design boutique led by artist and programmer Benjamin Borowski; committed to creating fine interactive applications via direct and collaborative engagements. Providing strategic design and development for websites, games, and mobile devices, our core expertise melds hand-crafted code with beautiful, user-centric design & strategy.
Comcast provides a rather obnoxious service called a Domain Hijacker Helper which acts as a layer on top of their DNS service and redirects you to a branded Comcast search page if a domain you are looking for doesn't exist. Their site indicates that "you can login to Comcast customerCentral and change your preference immediately for Domain Helper." Sadly, this preference no longer actually exists in your account settings and it's still active even though their site indicates that it will be "phased out by the end of March 2011". If you are still getting this annoying page and want to disable it, you just need to add Comcast's national DNS servers to your setup.
On Mac OSX:
- go to Settings > Internet & Wireless > Network and click on Advanced…
- Click the DNS tab.
- Click the "+" under the DNS box and add two entries:
- Click OK
- Click Apply
While you're in there, you might as well just set your DNS servers to Google's Public DNS instead of Comcast's:
As it says in their docs, you are changing your DNS "switchboard" operator from your ISP to Google Public DNS. This is probably a good thing for speed of DNS lookups and, thus, browsing speed.
This also removes the Comcast Domain Helper. Google's documentation on Configuring your network settings to use Google Public DNS also provides instructions for configuring DNS servers on Windows XP/7 if you need those.
This week was an incredibly rough week for Flash and Flex Developers. Adobe announced that it would cease active development of the Mobile Flash Player, choosing instead to focus on developing tools, solutions, and browser processes targeting "universally supported" (accuracy of this statement somewhat dubious) HTML5. The Flash Platform will continue to be developed in what seems to be a more focused manner—the Flash Platform being streamlined to mobile applications packaged with Adobe AIR and more innovation with tools related to gaming and video. That's great, and it's really not news if you consider it. Adobe has regularly been mentioning this direction over the past few years and this sounds in line with its inability to attain the Flash Player's same ubiquitous installation base in the mobile space as in the desktop space.
The major pain was more sharply felt when Adobe dropped their second bombshell of the week: the announcement that Flex would be donated to an open-source foundation and that "[Adobe believes that] HTML5 will be the best technology for enterprise application development." For developers who've invested many years in Flex development, I'm sure this felt like a solid punch in the gut. This was no more apparent than in a mass-flash-developer community video chat last night where many developers cried foul on Adobe's handling of its "abandonment". Topics included...
- How are we supposed to explain to our clients that Flex is a viable technology for their Enterprise product when the makers of said technology are saying what amounts to "HTML5 is better?"
- What's the migration plan?
- Where are my HTML5 tools that allow me to start making kick-ass HTML5 apps right now?
These and other questions were posed, often in a tone of considerable vitriol. Well, I'd like to address some of the statements and questions made during this chat. Naturally, these are completely my opinion, so feel free to tell me yours at @typeoneerror on Twitter. I wrote some of these somewhat ranty sections while listening to the Flash community video chat last night so they aren't really in any meaningful order.
"How do I explain this to my clients?"
Communication is everything. Adobe certainly has made this clear with their lack thereof. With your clients, present the facts and the facts only. Your client ultimately pays you to develop their Enterprise product, so if they decide that their application should run on iPad, you need to solve that problem for them. You cannot look to solve creative problems with a technology-first mindset. It's a square peg/round hole situation; trying to apply Flash to everything is somewhat foolish. Is interactive even the best solution to your client's problem? Maybe it's a motion graphics piece instead? You cannot blame a corporation if you cannot answer that challenge, only yourself, right? Can I package it as an AIR app? Will I have to completely remake it using HTML5 technology? Which leads to...
"Flash is better than HTML5!"
Of course it is (and you know it so well, so that helps), but that's not what this is about. You need to be able to provide your clients with business solutions. That could be a Flash app, that could be an HTML5 app, hell, it could be a knitted wool cap...the point is, if it makes sense for the client, then that's the tool you should use. If you don't like the HTML5 technology stack and don't want to do web development with its technologies, you should focus your considerable skill on something else. Simple, right? Again, communication is key. Manage expectations. "You want that massive enterprise app rebuilt in HTML5? OK, not a problem, let me just be clear it's going to take twice as long and cost twice as much." That's the reality. That would be your or your client's decision to weigh whether that cost is a good business decision.
"Now I have to do browser/device testing."
No, you don't; not if you don't want to. Think how easily your Flash API knowledge could be applied to Unity 3D, or decide to pick up C# and focus on XNA gaming and push apps to Xbox, Windows and Windows Phone 7. Pick up Objective-C and make iPhone apps (check out the Sparrow Framework inspired by the Flash API!). The point is, don't be completely tied to a single technology. Performing quality assurance is just about the worst part of being a web developer, so if you don't want to do it, you may have to try a platform that is a bit more locked down.
"It costs more to develop in HTML."
A boatload more—tell me about it. Boy did I love the days back when I was the technical director at BKWLD when all we did was develop Flash sites. Save, Publish, Upload...hey QA is done! So, HTML apps take a bit more time to QA. You should factor that into your costs if an HTML app is the best solution for the project. Simple as that. BKWLD recognized the value of a non-flash product a few years ago and split the company in half to form the successful ground(ctrl). BKWLD's music sites prior to this were generally 100% Flash. ground(ctrl) has these same clients, but different technology. Expectations managed. It is not Adobe's responsibility to provide solutions for your clients, it's yours. If Adobe's corporate decisions aren't working out for you, move on to something that does.
Find some new stuff you like working with and offer those as solutions for your clients. For an example of this, how about following two Sean M's I know. Sean Monohan (@noobsarepeople2) is building a XNA-based game at the moment which has a Node.js backend and level editor. Guess what Sean does during the day? Flex developer. If Sean had to give up Flex completely today, I know he'd be happy to try other things. I know the guy just wants to make cool games, regardless of the technology. Having interests outside of his client work allows him that freedom. Sean McCracken (@seantron) is a Unity 3D development and also does iOS and Android development. He also works at Red Interactive (where I'd guess he does some Flash work here and there). Again, point is that you can apply all this Flash Platform knowledge to other pursuits. It's not giving up on Flash, it's just broadening your creative approach.
"Show me one good HTML5 app."
Facebook.com. Bigger than any enterprise app you've ever built, guaranteed. What is an HTML5 app anyway? Look at their doctype.
<!DOCTYPE html>. Is this HTML5? Yes and no. Very little actual HTML5 markup, lots of modern web technologies used that we are now lumping under the HTML5 masthead. Point being, web technology that is not plug-in dependent. An application does not have to do what Flash can do to be successful.
"Adobe left us with no migration plan."
No one in their right mind will say that Adobe has a great history of PR and communication with its developer base. It's also a corporation. If you decide to put all your chips in with a single technology, you will eventually get burned. Tech moves too fast. But what have you learned in your many years of Flex and Flash dev? Personally, Flash gave me a unique way at looking at product development. Besides teaching me object oriented programming, the Flash Platform helped me learn asset management in a programming context, how to programmatically animate assets, and especially important, I feel, is a distinct separation of concerns between logic and visuals. As Joel Hooks (who happens to be one developer who makes me confident that Flash has a great future ahead of it) succinctly put it "your skill-set is not the Flash Platform"; it's creating rich interactive experiences. This overarching knowledge can easily be applied to other platforms and technologies. You should certainly continue to develop in Flash (I do, and I still love it), but diversify.
"I can't make Enterprise apps in HTML5."
This is just a cop-out to me. Unless your enterprise app is a asset-heavy game, video/streaming presentation software or something similar (the places where Flash excels according to Adobe), there's no reason you cannot build an incredibly successful HTML-based application. You can also likely charge more for it because it'll likely be inherently more difficult to produce.
"Adobe betrayed us."
Reality check: Adobe is a corporation. They will make business decisions that make sense (in theory) for them monetarily. As a developer, you've got to make tough decisions about which technologies to devote time learning. If you've been doing nothing but Flash development for the past decade, that is a huge gamble. One that probably paid off very well for you until late (I paid the bills as a Flash dev for close to 6 years). In this case, it's time to—as they say in finance—diversify your portfolio. Risk management and reduction.
In Adobe's press release, they state that Flash "has repeatedly served as a blueprint for standardizing new technologies in HTML." This could not be more true, and will, of course, continue to be true. Flash is incredibly powerful; the majority of the cool functionality we are now seeing being recreated in modern "web" technologies all have roots in what Flash enabled us as creatives to do. Full screen, responsive, liquid layouts; effects; animation; video; et al. So what if HTML5 isn't perfect yet; the technology will move faster than any individual can learn it, so it won't take long (just compare Flash 4 to Flash 8) to catch up.
Looks like the open-source foundation that will be taking over the Flex SDK is Spoon.as. And perhaps "taking over" is a misleading phrase; the SDK's development will still be lead by developers from the Flex SDK team; it just won't be backed by Adobe (seemingly).
Having a look at the people on the board of directors, it's clear to me that the Flex SDK will continue to be a viable platform for the foreseeable future. In fact, "removing" it from Adobe's clutches may be the best thing for it in the long run (less bureaucracy, more code, right?). Looking at something like the Robotlegs community/team, again, I'm confident that as long as the Flash Player itself continues to be developed, there'll be lots of room for Flex and AIR projects. Some clients and companies will start using more HTML5 technologies, but there'll be plenty that will settle—nay, opt—for the amazing capability of the Flash API internally and for Enterprise solutions. If you really want the Flex/Flash community to thrive, I'd imagine the best thing you can do is sign up to support Spoon.
My personal plan
- Support Spoon.
- Continue to let Adobe know that Flash is an important platform by using it to make kick-ass applications and games.
- Support awesome projects like Robotlegs.
- Use Flash where it makes sense and achieves client goals, and
- Use HTML5 and supporting technologies with the same intent.
Thanks for reading. Hopefully you found these thoughts positive and useful. Please let me know if so.