A bright star in the JavaScript community, Addy Osmani has skyrocketed to prominence not only for his fabulous JavaScript articles and open source contributions but for also being one of the friendliest and approachable developers around.

His blog is a treasture trove of front-end knowledge and well-worth the visit. In this post, we'll chat with Addy about how he got his feet wet in JS and bring up some tough topics relating to his work in developer relations at Google.

JavaScript was going to play a large role in making this possible.

I wrote some of my first JavaScript back when Netscape Navigator was the dominant browser. Dynamic front-end development was only slowly starting to becoming more popular at the time, but the idea of being able to write something with just HTML/CSS/JS and have it work everywhere was powerful. I got hooked on to that idea and have been ever since. Some of my first creations were little things you would laugh at today – calculators, password generators, nothing too amazing.

As a language enthusiast, I liked that JavaScript was prototype-based and weakly typed, so I decided to continued learning it alongside other languages like C++. Back in the early 2000's, I tried bridging the languages by writing a little interpreter on top of SpiderMonkey (Mozilla's JavaScript engine), which let me write logic for my desktop apps in JS and define UI components using C++. It was a silly idea, but I learned a lot about JavaScript engine internals in the process.

I spent a lot of time building small hobby sites, but when I was in my last year at high-school, I decided to really get stuck into the world of browser internals. I wrote a lightweight rendering engine, basic HTML 4.01/CSS 2.1 parsers and wrapped all of these parts into my own little browser. The project was a nightmare to get working reliably, in part due to how lax web developers were with standards-compliance in their pages – it's funny being on the other side of the fence now! The larger challenges were spec-compliance, rendering large tables and maintaining performance, whilst loading up video plugins (anyone remember good ol' ActiveX?).

I continued learning and using JavaScript as a freelance web developer while in college, slowly writing more complex sites and playing around with Dojo. It wasn't, however, until I got an invitation to GMail in 2006 that it occurred to me that the browser was going to be the next platform for building rich applications. JavaScript was going to play a large role in making this possible and I decided to walk away from desktop app development permanently.

Since then, I've been trying to continue learning and where I can, push the front-end community forward through my writing and contributions to open-source. JavaScript is virtually everywhere today, and it's one of the reasons why I love the language. If I want to teach one of my kids how to author JavaScript, I can just pop-open my browser DevTools and show them. No additional compilation steps needed – there's something really special about that.

If you leap into any non-trivial topic with that mindset, it's necessary to break it down into simple, more easily digestible steps

The secret is that I consider myself to be somewhat stupid. Really. If you leap into any non-trivial topic with that mindset, it's necessary to break it down into simple, more easily digestible steps in order for it to make any semblance of sense.

It's this perspective that I think makes my writing feel accessible – I try to make sense of those concepts or tools that can initially feel quite daunting to the average developer. It's important to be able to apply this to articles and especially documentation. So, keep it simple. This helps make articles more focused. How do I generate so much content whilst understanding the material?. Well, I make understanding a prerequisite.

First do it, then do it right, then do it better.

Einstein has this great quote: "If you can't explain it simply, you don't understand it well enough" and it's true. You cannot teach about or claim a framework, tool or best practice, unless you've actually taken the time to use it yourself. Finding this time is easier in my current role, but back in my days as a 9-5 engineer, I would spend time over breakfast and lunch actively using what I would later write about on the weekend.

Finding time to get everything done is always a challenge. For the past few years, I have this mantra that I try to apply to every task – “First do it, then do it right, then do it better” – it's all about setting realistic goals for yourself and iterating fast as soon as you have something that just works. It won't be the most eloquently written article, nor the most beautiful code, but it's a simple baseline you can build on.

You can then share this first iteration with your peers and get a feel for whether you're going in the right direction or the idea is worth pursuing. To me, that makes a great deal more sense than spending weeks on a draft or prototype before asking for input.

There's something special about being a part of a company with such high standards.

Both AOL and Google are companies with terrific engineering teams, and any of my reflections of culture aren't about any specific groups, more a general observation.

The engineering culture at Google is such that we care a lot about polish and shipping things when we feel they're just right. There's something special about being a part of a company with such high standards.

At AOL, I was proud of any of the products or applications we completed, but due to the fast-paced nature of business and competition, delaying launches or releases for polish wasn't always feasible. I think that's a reality for many businesses, despite any desire they may have to change that culture.

When it is possible to delay releases to, as Google say, get it "right" I think it can make a world of difference to your users first impressions of your product.

I'm pleased with the direction TC39 have been taking over the past few years.

I'm pleased with the direction TC39 have been taking over the past few years, which in part has been helped with the involvement of Rick Waldron and Yehuda Katz from the jQuery project. They've paid close attention to the patterns and libraries developers have been heavily relying on, and investigating how these could be better solved using platform primitives. I won't comment on ES6 specifically, but I'm looking forward to seeing modules, classes, 'let' and Object.observe() available more widely.

On the JavaScript community: we're in a good place but the one thing I wish we would collectively do is spend less time creating new frameworks and more time investing in efforts to improve existing solutions. I think it's fantastic that developers are spending time learning how to solve problems on their own – it's one of the best ways to learn new things – but if it's an experiment, make that clear so that other developers don't expect you to maintain the project. That type of thing only adds to the noise, so please keep support in mind when releasing things!.

One of the big myths out there is that it exists to replace JavaScript.

I was actually super curious to learn more about the goals Dart had when I first joined Google. One of the big myths out there is that it exists to replace JavaScript, but it turns out that this isn't quite true. Dart is targeted at those developers more familiar with Java, C++, C#, who are trying to build high-performance web apps; and so on that, have certain expectations around their tooling and language. I think that's a legitimate reason for something like Dart to exist.

As a company, both JavaScript and Dart are technologies that we believe in and invest in. We participate in TC39, working on the future of JavaScript and also continue work on V8, the fast JavaScript engine. The Chrome engineers continue to work to push the web forward with new specs like Web Components. Meanwhile, the team that originally built V8 is now building the Dart VM.

Back to your original question – I believe forking WebKit was a lot more to do with the divergence of the multi-process architecture between both projects than trying to embed Dart into Chrome. Dart's a separate open-source project with it's own goals and you can still get Dartium today (the build of Chromium using the Dart VM).

When I first heard the news about Blink, I was concerned that we'd now have another browser to support.

The reality, however, is that there have already been so many differences between the various WebKit ports that this isn't going to negatively impact how you develop and test.

In fact, Blink allows us to give developers more of the tools, features and compatibility they need to get the most out of the web as a platform. Long-term it's going to let us prioritise features that will ease building the next generation of web apps and in the same way that V8 gave us a way to speed up JavaScript, I think Blink is going to let us innovate in ways that will benefit the whole platform.

We get caught up in the debate about native vs. web quite often these days, but don't talk as much about the need to put our users first. They're the focus. There are many cases where you can deliver a compelling experience for the web on desktop and mobile and it'll work fantastic. That said, there are others, where either the platform or mobile browsers still need work. As a business, you often need to make a call on what makes the most sense for your users. I think that, at present, it makes a great deal of sense to offer developers the best platforms possible for making a call on native vs web, and that's what we do, via Android and Chrome for Mobile.

Reusable components.

Reusable components. Traditionally, a lot of us have developed applications quite vertically, spreading a single concept (whether it be logic or UI) across a few different parts of the project. Not only does this make it harder to maintain the idea but it also makes it difficult to extract and reuse the idea in future applications without a great deal of effort. It also decreases our chances of being able to share the component with others.

Without referring to specific technologies, we're working on making it easier to define and package up components on the web platform side, and now is a great time to start thinking about how your own apps might be written, if they were broken down into specific components.

The front-end is seeing a revolution in tooling at the moment with an increasing number of developers starting to use Grunt and explore workflow tools around it like Yeoman. Developers are paying more attention to what they can automate and I think that this will help facilitate more time spending building better apps and less time on those manual processes in between.

Going back to the components idea, I think that between web components and front-end package management we have a huge opportunity to really shift the way we develop for the web. AngularJS (and Angular directives) have done a great job of re-introducing the idea of reusable blocks of functionality and things are really looking up on the package management side of things, through Bower.

Writing an app with lists you want to make sortable? Great. A few keystrokes at the command-line and you've got that. Want to make the items in that list persist when you're offline? No problem. A few more keystrokes and you're using a package another developer once had to write to get that capability. Want to turn your list into a reusable component anyone else can use? That's easy. That's the future we're working towards.

We're fortunate to have a wealth of helpful tools at our disposal on the front-end these days – tools that save us time and make our lives just a little bit easier. Abstractions like Sass and CoffeeScript, frameworks like Twitter Bootstrap, module loaders like RequireJS, a never-ending list of MVC and unit testing libraries…some would say we're spoiled for choice and it's interesting seeing how long it can take you to get a project started up.

Are you still manually refreshing your browser whenever you make a change to your app?

As much as these tools work exceptionally well on their own, it can be a tedious process getting them to work together, especially if you have to put together a workflow and build process where they all compile and get optimized succinctly. Even if you do manage to get a solid build process in place, you're often left having to spend a great deal of time writing out the boilerplate code for your application.

Even then, you have to ask yourself how well this fits in with your day to day workflow. There are several little steps we repetitively do while developing which can more easily be handed off to tooling. Are you still manually refreshing your browser whenever you make a change to your app to preview how they look? Still trying to figure out whether you're using the latest versions of all your dependencies? Wondering if there was just something that let you get on with coding and forget about a lot of the grunt work?

We were too, which is why we started looking at whether we could give developers a solution to many of these common problems. We tried solving them in a free, open-source project we recently released called Yeoman. Yeoman's official tagline is that we're a “robust and opinionated client-side stack, comprised of tools and frameworks that can help developers quickly build compelling web applications�.

Practically, we're a series of tools and tasks that help you achieve automate some of the more tedious tasks in front-end development. We're composed of yo (the scaffolding tool), grunt (the build tool) and bower (for package management).

If you find that you're still writing boilerplate code for your application, manually managing the dependencies for your apps or putting together your own build system to work with the tools you love, you might find Yeoman a nice way to save yourself some headache.

The Windows developer community could really help us here.

Creating a command-line tool that works well cross-platform can be a delicate dance. One of the initial challenges with Windows support was that a lot of our team were used to using a *nix system and having access to homebrew/apt-get. We weren't however as well versed in using PowerShell or Chocolatey (the PowerShell-based Windows equivalent to apt-get) and needed time to understand how well these solutions compared to the tools we had available elsewhere.

It then took time to find (or get) all of the packages we required up on Chocolately as we needed git, phantoms, opting and many others. The situation there has greatly improved since our first release and Windows is now officially supported with Yeoman using the instructions on our homepage.

The Windows developer community could really help us here by advocating for more widespread adoption of tools like Chocolately and helping us reach parity with tools like apt-get. Other than that they've been fantastic and we've really appreciated the help and support the Windows developer community have offered us throughout our road to compatibility.

I've got to give a call out to Sindre Sorhus, Mickael Daniels and Paul Irish, all of whom really helped improve our Windows efforts in the early days.

At the moment, there are a lot of (fantastic) development tools being written which are not just *nix, but Mac specific because making them cross-platform has it's own development costs and overhead. I would love to see more open-discussion and development of tools that can work everywhere, but this can't be done without the help of users.

If there's a tool you want for Windows that you just see on Mac, please be vocal about it – even better, submit a pull request!

Try to find out what it would take to bring it to Windows (and elsewhere) and who knows? Maybe the combined efforts of multiple communities would be enough to make something happen.

Releasing my first book, Learning JavaScript Design Patterns (with O'Reilly) was probably the accomplishment that's given me the greatest satisfaction. It was my largest writing project, and I made the decision for it to be completely open-source from the start – a call I'll never regret. Making educational material available to anyone, anywhere whether they can afford it has the potential for a great deal of both good.

It also has the potential to increase your book's impact, so if you're an author – please consider doing it. You won't regret it!

Destination Innovation Recognizes Outstanding Efforts in Technology Advancement

On Monday, May 6, nearly 200 members of the technology community gathered at The Washington Post Headquarters as 20 of the region's innovators showcased their company's technologies at Destination Innovation. Presented by the NVTC Technology Innovations Committee, in partnership with Capital Business, this fresh and fast-paced event highlighted technology advancements emerging from our region and connected innovators from both large and small companies with parties interested in collaborating on technology development and job creation.

Lookingglass Cyber Solutions was among the 20 presenting companies at Destination Innovation on May 6.

The event featured remarks from Magid Abraham, president, CEO and co-founder of ComScore Inc.; Cory Haik, executive producer of digital news at The Washington Post; Mark Muehl, senior vice president of product engineering at Comcast; and Gary Shapiro, president and CEO of Consumer Electronics Association (CEA)®. All four speakers offered insights on how to foster innovation, including: finding great partners, developing a working product that customers want, embracing a willingness to fail, and thinking beyond the typical solution.

Along with the industry speakers, 20 companies gave five-minute presentations about their innovations and showcased their technologies to potential partners and investors on the exhibit floor. The presenting companies were: Berico Technologies, BetterPress, CFN Services, Compuware, Critical Power Group, DataRPM, GeoPay Inc., INF Robotics Inc., Light Point Security, Lookingglass Cyber Solutions, Microsoft, Oculis Labs, Rofori Corporation, ROI² Inc., Salient Federal Solutions, Sphere of Influence Inc., Sprint, SpydrSafe Mobile Security Inc., Triea Systems LLC and Verizon Wireless.

Representatives of award winner companies at Destination Innovation.

A panel of judges evaluated all presentations based on delivery and innovation. At the conclusion of the program, four companies were named winners in categories based on company size. Congratulations to the following winners: startup company winner Light Point Security, small company winner Oculis Labs, midsize company winner Berico Technologies, and large company winner Verizon Wireless.

In addition, NVTC introduced a new element to the competition this year – an audience choice award. Audience votes were collected via text message and each attendee was allowed one vote. Congratulations to Audience Choice Award winner BetterPress.

Video of the industry speakers and 20 presenting companies, as well as the company presentations, will be available on www.nvtc.org later this week.

We are excited to announce a fantastic new workshop led by Instructor Tom McFarlin: Introduction to WordPress Plugin Development

Are you an aspiring WordPress developer? Are you ready to take the next step and start building your own custom plugins for WordPress? Our newest Tuts+ Live Workshop is the perfect way to get started!

Tickets are a great investment at $99, but places are strictly limited so act fast to make sure you don’t miss out!

Introduction to WordPress Plugin Development

Our newest Tuts+ Live Workshop, Introduction to WordPress Plugin Development, teaches you everything that you need to know to start developing WordPress plugins; from setting up a local development environment, all the way through to building a WordPress plugin that’s ready for release into the WordPress Plugin Repository.

It’s led by Instructor Tom McFarlin, a self-employed WordPress developer who divides his time between running his own WordPress development shop, building plugins for WordPress, blogging every day about software development in the context of WordPress, and working for 8BIT (the team responsible for Standard Theme and WP Daily).

Each weekly workshop will last one hour, running over a five week period. You’ll have the opportunity to follow along with Tom, ask questions live during the workshop, and complete a weekly homework assignment. Not able to make it to the live recording? No problem! All of the workshop recordings will be made available online the day after the live workshop.

Learn more about Introduction to WordPress Plugin Development

Sign Up to Our Newsletter

If you’re interested in future workshops then definitely join the Tuts+ Live Workshops mailing list to stay posted on upcoming workshops and get notified as soon as they’re available, the Early Bird tickets for our previous workshops have all sold out, so it’s worth getting ahead of the game!

We’re really excited about new workshop, Introduction to WordPress Plugin Development, but places are strictly limited so act fast to make sure you don’t miss out!

Adobe has just announced that Creative Suite will cease to exist after CS6 (in name at least), and be replaced exclusively by Creative Cloud. On its most basic level, that means there won’t be perpetual licenses for future Adobe products (though, for now, you’ll still be able to buy CS6 in that format) and instead all of their Creative Cloud software will be available by subscription only.

For creatives, this is a huge shift. Adobe has been the leader in graphics and web software for years (especially after their purchase of Macromedia), and designers and agencies are used to the perpetual license model. I’ve already been hearing complaints from some colleagues unhappy with the switch, though many of their complaints don’t really have much merit if you really break them down.

$50 a month?!?!

The price is probably the most common complaint I’ve been hearing. But if we break it down into long-term costs for the subscription compared to the cost of the perpetual licenses, the subscription actually comes out on top.

A new (not upgraded) license for Creative Suite 6 Master Collection is US$2,600. An upgrade license will cost you anywhere from $550 (if you already had the CS5.5 Master Collection) to over $1,000 (if you had any of the other CS5 or 5.5 products). Adobe has historically offered major upgrades every 18 months or so, which means the monthly breakdown is between $30 and $58 per month. And if you have to buy the entire Creative Suite new, then you’re looking at a cost of over $144/month for 18 months.

Adobe is offering CC subscriptions for new users for $50/month, and for “upgrade” users for just $30/month for the first year (and CS6 users will get an even steeper discount for the first year). The other big advantage is that you won’t have to fork over a large payment up front. This makes it much more affordable for new designers or small agencies, and will obviously reduce start-up costs for new freelancers or agencies. This could encourage a lot of great designers to strike out on their own.

I don’t want my work in the cloud!

The good news is that you don’t have to host any of your work in the cloud, and the software itself runs right on your computer, not online.

Granted, the cloud offers a lot of great features you might want to take advantage of, but there’s nothing that says you have to. You can keep using your CC products just like you’ve been using CS products for years.

And if your internet connection is down (either on purpose or because of connectivity problems), you don’t need to worry about your software not working. It only needs to connect to validate your license every 30 days, and with the annual plan it will still work for over 3 months (99 days) without validating. Of course, without internet access you won’t be able to access online CC features, but the software on your computer will still work fine.

But how do I pirate something in the cloud?

Okay, I haven’t heard this one expressed directly, but I’ve heard grumblings where the subtext is basically the same thing.

My answer for this is that you really shouldn’t be pirating the software in the first place.

Without getting into the entire moral and ethical debate surrounding software piracy and when it is or isn’t acceptable, let’s look at one small aspect of it: the biggest reason given for piracy is often that the product isn’t affordable. I can see where that was the case with CS, as it’s a very expensive professional program. Obviously your hobbyist or entry-level designer might not want or be able to spend thousands of dollars on software.

But Creative Cloud removes that expensive start-up cost. Most professional designers using Creative Suite products are making well over $50/month with the software. And there are free and low cost alternatives that will meet the needs of most hobbyists if they don’t want to spend that kind of money on a monthly basis.

I understand the frustration that many people who design as a hobby or just like to “play around” in Photoshop or another Adobe program, but at the same time, it’s certainly not Adobe’s job to make it possible to use their products without properly licensing them.

Adobe maintains that the added difficulty in pirating their products had nothing to do with their decision to transition to an entirely subscription-based product line, but I’m sure they’re finding it to be a nice little added bonus.

I only use Photoshop/Illustrator/etc! I don’t want to pay for everything!

There’s good news here: you don’t have to. There are plenty of people out there who only use Photoshop, or Illustrator, or any of the other Creative Cloud/Creative Suite products. And for those people, you can subscribe to just one program at a discounted rate of US$19.99/month.

This is a great option for those people who only use one product (like photographers who only use Photoshop or visual effects designers who only use After Effects).

More about the new subscription model

Students and teachers will still be able to get Creative Cloud at a deeply discounted rate of US$19.99/month ($29.99/month after June 25). The big bonus here is that they’ll get access to all of Adobe’s programs, rather than just the one or two they might need for their classes.

This opens up a lot of creative possibilities, as students and teachers will be able to more easily branch out into other media. We’re likely to see more designers familiar with motion graphics, more video editors proficient in audio editing, more photographers proficient in design, etc. And of course we’re more likely to see interesting projects coming out that combine disciplines.

In addition to the basic Creative Suite programs we’ve all become accustomed to, Creative Cloud offers some additional tools you might not have used before.

There’s the Digital Publishing Suite, which lets you create content and publish apps. There’s ProSite for managing and building your own professional portfolio site. Business Catalyst offers tools for website hosting and management. And Story CC Plus is available for collaborative screenwriting and production tasks (like scheduling and reporting). These are apps that a lot of designers and other creatives may not have tried before, but without any added cost, there’s no excuse not to now.

One of Adobe’s main reasons for switching to the cloud model is the ability to constantly update products and add features without a major product upgrade. These constant updates are good news for the creative community.

The verdict?

While transitioning to the cloud is going to be an unwelcome change for some designers and other creatives, overall, I think it’s good news for the industry and for creative pros. You’ll have access to more programs and more features for less money. And you’ll get updates on a more consistent basis, without added cost.

While I’m sure we’ll continue to hear complaints from some sectors of the design community, overall I think most creatives will embrace CC once they give it a chance.

Are you already a Creative Cloud subscriber? Are you happy about the change or do you have reservations? Let us know in the comments!

3,000 Items! MEGA Design Bundle – only $49!

Adobe has just announced that Creative Suite will cease to exist after CS6 (in name at least), and be replaced exclusively by Creative Cloud. On its most basic level, that means there won’t be perpetual licenses for future Adobe products (though, for now, you’ll still be able to buy CS6 in that format) and instead all of their Creative Cloud software will be available by subscription only.

For creatives, this is a huge shift. Adobe has been the leader in graphics and web software for years (especially after their purchase of Macromedia), and designers and agencies are used to the perpetual license model. I’ve already been hearing complaints from some colleagues unhappy with the switch, though many of their complaints don’t really have much merit if you really break them down.

$50 a month?!?!

The price is probably the most common complaint I’ve been hearing. But if we break it down into long-term costs for the subscription compared to the cost of the perpetual licenses, the subscription actually comes out on top.

A new (not upgraded) license for Creative Suite 6 Master Collection is US$2,600. An upgrade license will cost you anywhere from $550 (if you already had the CS5.5 Master Collection) to over $1,000 (if you had any of the other CS5 or 5.5 products). Adobe has historically offered major upgrades every 18 months or so, which means the monthly breakdown is between $30 and $58 per month. And if you have to buy the entire Creative Suite new, then you’re looking at a cost of over $144/month for 18 months.

Adobe is offering CC subscriptions for new users for $50/month, and for “upgrade” users for just $30/month for the first year (and CS6 users will get an even steeper discount for the first year). The other big advantage is that you won’t have to fork over a large payment up front. This makes it much more affordable for new designers or small agencies, and will obviously reduce start-up costs for new freelancers or agencies. This could encourage a lot of great designers to strike out on their own.

I don’t want my work in the cloud!

The good news is that you don’t have to host any of your work in the cloud, and the software itself runs right on your computer, not online.

Granted, the cloud offers a lot of great features you might want to take advantage of, but there’s nothing that says you have to. You can keep using your CC products just like you’ve been using CS products for years.

And if your internet connection is down (either on purpose or because of connectivity problems), you don’t need to worry about your software not working. It only needs to connect to validate your license every 30 days, and with the annual plan it will still work for over 3 months (99 days) without validating. Of course, without internet access you won’t be able to access online CC features, but the software on your computer will still work fine.

But how do I pirate something in the cloud?

Okay, I haven’t heard this one expressed directly, but I’ve heard grumblings where the subtext is basically the same thing.

My answer for this is that you really shouldn’t be pirating the software in the first place.

Without getting into the entire moral and ethical debate surrounding software piracy and when it is or isn’t acceptable, let’s look at one small aspect of it: the biggest reason given for piracy is often that the product isn’t affordable. I can see where that was the case with CS, as it’s a very expensive professional program. Obviously your hobbyist or entry-level designer might not want or be able to spend thousands of dollars on software.

But Creative Cloud removes that expensive start-up cost. Most professional designers using Creative Suite products are making well over $50/month with the software. And there are free and low cost alternatives that will meet the needs of most hobbyists if they don’t want to spend that kind of money on a monthly basis.

I understand the frustration that many people who design as a hobby or just like to “play around” in Photoshop or another Adobe program, but at the same time, it’s certainly not Adobe’s job to make it possible to use their products without properly licensing them.

Adobe maintains that the added difficulty in pirating their products had nothing to do with their decision to transition to an entirely subscription-based product line, but I’m sure they’re finding it to be a nice little added bonus.

I only use Photoshop/Illustrator/etc! I don’t want to pay for everything!

There’s good news here: you don’t have to. There are plenty of people out there who only use Photoshop, or Illustrator, or any of the other Creative Cloud/Creative Suite products. And for those people, you can subscribe to just one program at a discounted rate of US$19.99/month.

This is a great option for those people who only use one product (like photographers who only use Photoshop or visual effects designers who only use After Effects).

More about the new subscription model

Students and teachers will still be able to get Creative Cloud at a deeply discounted rate of US$19.99/month ($29.99/month after June 25). The big bonus here is that they’ll get access to all of Adobe’s programs, rather than just the one or two they might need for their classes.

This opens up a lot of creative possibilities, as students and teachers will be able to more easily branch out into other media. We’re likely to see more designers familiar with motion graphics, more video editors proficient in audio editing, more photographers proficient in design, etc. And of course we’re more likely to see interesting projects coming out that combine disciplines.

In addition to the basic Creative Suite programs we’ve all become accustomed to, Creative Cloud offers some additional tools you might not have used before.

There’s the Digital Publishing Suite, which lets you create content and publish apps. There’s ProSite for managing and building your own professional portfolio site. Business Catalyst offers tools for website hosting and management. And Story CC Plus is available for collaborative screenwriting and production tasks (like scheduling and reporting). These are apps that a lot of designers and other creatives may not have tried before, but without any added cost, there’s no excuse not to now.

One of Adobe’s main reasons for switching to the cloud model is the ability to constantly update products and add features without a major product upgrade. These constant updates are good news for the creative community.

The verdict?

While transitioning to the cloud is going to be an unwelcome change for some designers and other creatives, overall, I think it’s good news for the industry and for creative pros. You’ll have access to more programs and more features for less money. And you’ll get updates on a more consistent basis, without added cost.

While I’m sure we’ll continue to hear complaints from some sectors of the design community, overall I think most creatives will embrace CC once they give it a chance.

Are you already a Creative Cloud subscriber? Are you happy about the change or do you have reservations? Let us know in the comments!

3,000 Items! MEGA Design Bundle – only $49!

The HTML Working Group has published a Working Draft of Encrypted Media Extensions. This proposal extends HTMLMediaElement providing APIs to control playback of protected content. See the blog post on this publication and learn more about the HTML Activity.

Hello!

Final exams are quickly approaching.  Enjoy some brain food to fuel a study session ON ME!!  

All iCubed Team Study Group participants in a study group are eligible to enter. Please fill out the study group registration form (attached) and return to me today (FRIDAY, May 10th), to be entered into a raffle to win 2 PIZZAS for you and your study group on UMBC Study Day (May 15th).   

For those of you not in a study group yet, it is not too late!  If you need assistance, I can help you find one.  For more information or if you have questions, please feel free to contact me,  stop by during my office hours (on Wednesdays in the dorms), or stop in my office in University Center 116.

Thanks!

-- 

Tashauna Felix, M.S., Ph.D.

iCubed Study Group Coordinator

University Center 116

tfelix1@umbc.edu

410.455.3173