Tag Archives: Adobe

How did you become an Adobe Evangelist?

Yesterday via twitter, I was asked a very ironic question:

So tell me @tpryan how does one become an @Adobe evangelist?! I must know.
ThinkCreativeKC

I figured I would give answering it a go. Keep in mind that I did this 5 years ago when Adobe was trying to do very different things. I don’t know that this would land you at Adobe anymore. I distinctly think it wouldn’t. See the job I originally landed was “Developer Evangelist.” I slowly morphed into being a broader design focused evangelist over the past 5 years as Adobe’s focus on developers waned and more and more people were focused on Creative Cloud. So this wouldn’t work at Adobe today but it could land you at a developer focused evangelism/advocate role at another company.

Discover the role
My first introduction to the idea of an evangelist was Ben Forta in his role as ColdFusion Evangelist. I remember at the time being wowed that there existed a job where you had to fool around with new technology, blog about it, and talk about it at conferences. That seemed like a dream job, and I figured it wasn’t a career that you could plan for. It wasn’t until later I discovered that Ben wasn’t in a one off situation. There were developer evangelists all over the place.

Network for the role
A good friend of mine whom I met working at The Wharton School, Ryan Stewart, also was very much into the idea of being an evangelist. He ended up in the role before me and confirmed for me that was in fact an awesome job and that I could would be a good fit. I also met the a couple people connected with the product I really wanted to evangelize, ColdFusion. I connected with Ben Forta, Adam Lehman, and a few of the product managers. I also participated in the pre releases for the product, and got myself involved with Adobe’s user group community. All of these things gave me good connections and good name recognition with the people who would hire for the evangelist position. That wasn’t necessarily the reason I was doing any of it at the time. I was doing it cause I loved playing with the latest and greatest tech, and the community was very rewarding, but in retrospect these things helped me a lot.

Prepare for the role
At some point I decided I wanted the role, and I constructed the outline of a 5 year plan for getting the job. I looked at the externals of what an evangelist did. They experimented with the technology, showed how you could integrate it into other technology, and then they blogged about it and spoke at conferences. So I played with tech, got it to do new things, and then blogged and spoke about them. The idea was to prove I could do the job, before I was actually doing the job. This combined with my networking led to bigger and better speaking gigs, which allowed me to network more, which became a positive feedback loop.

Get Lucky
At this point I was a member of a pool of likely candidates for the role. I had applied once before. I knew everybody involved and had shown I could do the job. Then my friend Adam Lehman got hit by a car in London and was travel limited for a few months creating an opening for a replacement. And just like that my 5 year plan happened in 2. Luckily Adam recovered, and went on to do great things in product management. But it’s a terrible way to luck into a job.

For me it came down to being the right person and the right place at the right time. Some of that is preparation, and some of that is luck. You can control being the right person, in my case prepping for the role. You can have some control getting yourself in the right place, getting myself on the short list was partially in my control, by networking, but someone else made the call to keep me on that short list. And I had no control over Adam being hit by the car despite what some people may claim.

Some of these things would have to be updated for the current moment. Do you have to blog? Or is tweeting a combination of gist’s and github projects enough? Maybe, maybe not, but the main point here is that you have to explore tech and then share your findings. Are corporate sponsored users groups still as impactful? Or do you need to focus on meetups and regional conferences? Again the details aren’t as important as the fact that you are finding where peers and trend setters are, and engaging with them there.

So there you have it. Pretty much the way you get any other role. Figure out you want it, prepare your skill set for it, network with the people who do the hiring, and then assassinate anyone in your way be ready to take the opportunity if it comes up.

Goodbye Adobe…

After 5 years, Wednesday October 15th is my last day with Adobe. It’s fitting that my last duty for Adobe is a round of sessions at Max 2014. For me Max is the pinnacle of outreach at Adobe. As an audience member you get access to engineers, product mangers, and other experts from the community. My first had a profound impact on me. The very first entry on my blog is about Max 2004 – 10 years ago. The industry and what the event was all about was very different – back then, I was in the audience learning about ColdFusion, Flex and Flashpaper from Macromedia. This year I was on stage speaking about designer workflows using hosted cloud services for Adobe. It’s a very different world.

Five years after my first Max I got my dream job and joined Adobe. In the past 5 years, I’ve traveled over 560,000 miles to 119 or so cities. I’ve made friends all over the globe. And I’ve had a front view seats to some of the craziest technology fights we’ve ever seen. I’ve represented multiple technologies: ColdFusion, Flex, Flash, HTML5 and Creative Cloud. I’ve played with great toys. I’ve met most of my technical heroes along the way. It’s been a fun ride.

And now I’m leaving.

To all my friends I’ve met along the way, it was fantastic to have the privilege of talking technology with you all, and I hope to see you in the future. Keep in touch.

To my co-workers, it’s been a pleasure working with you.

To Adobe itself, you’ve been a great place to work, learn, and grow. So long and thanks for all the fish.

I have a next step planned. But in keeping with my traditions, I wanted to keep this a maudlin post about what’s behind me, rather than talk about what’s next. I’ll be blogging about that soon enough.

PANMA January 2014

panmaI’ll be speaking in the Philadelphia area this Thursday January 30th at the monthly Meeting of PANMA.

PANMA for anyone not acquainted with them is the Philadelphia Area New Media Association.  It’s a great group of people and it’s a great opportunity to network with people from various viewpoints in the digital world.  

I’ll be talking about getting your websites to work on mobile devices.  It’s a departure for me from my normal schtick.  I normally push responsive web design as the only real option, and recommend that you use Adobe Edge Reflow for it. I’m changing my tune a bit, as I realize that not everyone has access to the resources to make a pure responsive site happen.  So I’ll include other paths from Adobe, including Adobe Muse, Dreamweaver, Photoshop/Edge Reflow, pure code, and others.  We’ll see how it goes. 

Details:

Date: Thursday, January 30, 2014
Time: Doors open at 5:30pm. Program runs 6-7:30pm. Q&A and networking until 8pm.
Location: Room 260, Huntsman Hall, 3730 Walnut Street, Philadelphia, PA 19104

Please register: https://panma.eventbrite.com

I Used Reflow, Now What?

reflow

One of the most frequent questions I get when I show off Reflow is:

Once you finish creating something in Reflow, what is the next step? How do I make this cool resize-y thing show up on someone else’s screen when they go to a particular website?

It’s a tough question that doesn’t get you a super slick and quick answer yet. What it will get you is a few hundred words of “Let me explain.”

TL;DR: There isn’t a good workflow between Reflow and site development yet. But I still think it can be useful to you. 

Let me explain. Reflow doesn’t create an HTML site. It creates an HTML composition. I’m not just being buzzwordy; it’s a design tool. You create compositions with it, not websites. You still have to take what you create in Reflow and hand it off to a developer.  If you look at the tool, you’ll notice there is no facility for adding things like links or workable buttons.  You can draw these things using rectangles, rounded rectangles, and text, but you can’t create something in Reflow that allows you to click anywhere in preview.  You’ll also notice that the preview is only supported in Chrome, because Reflow isn’t trying to solve cross browser issues. Neither does Photoshop — because design tools don’t handle cross browser issues. Reflow creates something like a Photoshop comp but in HTML so it can be rendered in the browser and that you can be resized and viewed in a range of different screen widths.

But, I saw it in my browser, it creates HTML — you just said it did?

Oh, yeah, that.  Um, sure it creates HTML – sub optimal HTML. You see, I’m originally a developer, so suboptimal is short hand for terrible. And terrible is shorthand for I didn’t write it by hand, myself, while complaining about how designers want things that can’t be done in HTML and CSS.  

Assuming one doesn’t care about that, maybe you just want to get stuff done while not whining about code quality.  OK, you can totally grab that code and use it to start your site.  The code is located in the assets folder in the same folder as your .rflw file.

Well that’s an inefficient and poorly designed workflow.

It’s not inefficient and poorly designed, it’s nonexistent. There is no workflow there. What I’ve told you to do is a hack. From Reflow’s perspective there is a brick wall between designing in Reflow and developing for the browser.  That might be a deal breaker for you, and if it is I’m sorry but I won’t lie and say there isn’t a wall there — you’ll only be madder at me when you figure it out.  But I will point out there used to be a brick wall between designing in Photoshop and designing in Reflow.  That is now gone. I can’t talk about future plans, yada yada, but assume that the Reflow team is annoyed by all the brick walls around here and are resting for bit after swinging a pretty big sledgehammer with the help of the Photoshop team.

So what’s your workflow with these tools?

Personally, I design in the browser first and then Photoshop. Basically, my design chops and more importantly my Photoshop chops need work. I start designing where I can be the most facile, where there is as little impedance between my brain and creative output as possible. For me that is the browser and some CSS, for you that might be Photoshop or a pen and paper.  Once I get things like color, font, and site nuggets done in the browser, I bring it back into Photoshop. In Photoshop, I tweak color, font, and base layout. I also refine ideas for site nuggets, and things like borders, shadows, color interaction, etc. Once I get it done there, I move into Reflow.  Of course, once I start in Reflow, I have to do a little organization. Then I use Reflow to figure out where I need break points in my finished design, and how I will want the parts to move around. I also use it to figure out what I did in Photoshop that looks great static, but starts to look bad once I start resizing and moving things. Once I’m satisfied, I move to coding by hand. I do use Reflow’s ability to export CSS snippets to speed up this process. I also grab the HTML from the preview version, but I rip out almost all of the HTML because Reflow doesn’t create things like lists, or blockquotes, and the HTML isn’t very semantic. Basically, I use it to get the text, just the text.

So that’s it, like I said, lot of explanation instead of slick answers.  My hope is that slick answers and no brick walls happen in the future. But until then, I think there is a place for Reflow in a web design workflow, it just doesn’t get rid of a lot of work on the development side yet.

Quick MAX Post

MAX is coming. I’m in total, heads down, write-the-presos mode. I wanted to share what I’m heads down working on.  I’ll have 4 sessions at MAX:

Responsive Design in Action (Lab)

This session is a lab intended to get people up and running with Responsive Web Design. We start in Reflow, to get some of the basics, and then move to code to show how to do it as simply and cleanly as possible.

Programming in CSS

This is a run down of how to be more productive in CSS.  It will include some best practices, an overview of some modern techniques, and an overview of some tools to make writing CSS less of a pain.

Goal Oriented CSS

The idea behind this session to break down a design comp, figure out how to markup the vision, and write the CSS it takes to implement it.  I’ll try and tackle a few common design metaphors in the process. A few examples: iOS buttons, framed pictures with shadows, and vignettes to name a few.

Fast Performance with CSS on Mobile

I have the pleasure of tagging along with Paul Irish on the tools and techniques of writing high performance CSS targeting mobile devices.  It will also introduce you to ways of testing on devices that sometimes may be a little bit difficult to get into.

There are tons of other sessions, and of course there is the promise of a year’s subscription to Creative Cloud for all attendees.

If that wasn’t enough, here’s a discount code for $300 off: MXSM13.

So what are you waiting for, sign up! I hope to see you all in LA!

Upcoming Appearances – August 2012

I’ve got two events coming up in August that I want to let you know about.

First, I’ll be giving a general update of what Adobe is up to in the HTML world at the August Times Open meeting. I’ll be one of three speakers, the others beingAlex Komoroske of Google, and Eric Schorr from the New York Times.  If you don’t know about Times Open, it’s a series of small conferences run by the New York Times about technology for web developers in the New York area. It’s my first time there, but I’ve seen the rest of the work that the tech team at the Times does, so I’m very excited about this.  If you’re in New York, definitely check this out.

From New Amsterdam, I’ll be headed to the old one. I’ll be joining the rest of my team, Kevin HoytMihai Corlan, and Haresh Sivaramakrishnan in Amsterdam forAdobe Camp (link is in Dutch).  It promises to be an afternoon of Adobe HTML goodness. We’ll take a look at a number of Adobe HTML initiatives in some depth. It will be a great event.

Times Open
August 15
7:00 PM – 10:00 PM

The New York Times
15th Floor
620 Eighth Ave
New York, NY

Adobe Camp Amsterdam
August 23rd
12:00 – 18:30

Pakhuis de Zwijger, Amsterdam
Piet Heinkade 179
1019 HC Amsterdam

Embedded with the Web Platform Team – Features

I’m wrapping up being embedded with the Web Platform Team this week.  It’s been an awesome experience, and I want to share some of what I learned. Here’s some of it. 

Getting a feature into browsers is hard.

For the past few months I’ve been showing off a bit of this team’s work while talking to people.  CSS Regions, CSS Shaders, CSS Exclusions are the ones I usually hit. I always get hit with the question “When will this be in browsers?”  I never give a good answer to this, because I’ve never gotten a good answer to this, because there are not good answers to this.

So why is that? Because getting a feature into a browser is one of those iceberg things where what you see on the outside is only a fraction of the work involved.  

The engineers told me repeatedly that some of the prototypes for advanced features were demonstrable after a few weeks of work on their part.  They’re smart people who can do awesome things fast. But the prototype is just one piece of that, for us it only works in a specific build of WebKit, and can only handle what the engineers were trying to accomplish in the first place.

So how do go from there to other browsers as a whole?  Well you write a spec.  The spec tells the browser manufacturers what you want the feature to do, what the API of the feature will look like, what options are available, etc.  You write the spec and share it with other browser groups and they will tell you the spec is impossible because they’re engineers.  So, you whip out your prototype and show that it isn’t impossible. Take that, browser makers!

So to punish you for that, they tell you your spec is awful, and you need to rewrite the whole thing.  

This part of the process seems to go on multiple times. 

Then as you are perfecting your spec, some bleary-eyed engineer at one of the browser manufacturers pokes his head out of his cube and says “Look at this awesome thing I did!” and it will look a lot like the feature you have specced out. He or she didn’t see all the work on the spec, because they were too busy making the exact same thing happen. Except the API will be completely different.  And not, “they name this thing height, and we call it clientHeight” different.  No, it will be like the episode of Star Trek: the Next Generation where they find that culture that talks in metaphor, so you’ll call it “clientHeight” and they call it “Hixie and Zeldman at Tenagra.” 

So now you need to “reconcile” your APIs.  And by reconcile, I mean “argue that your way is better until you make the other guys ear gush out pink fluid.” Then who ever is left standing just does it the way they wanted. 

Then it gets into a few browsers, and people start using it.  Then they start complaining that other browsers don’t have it. This puts pressure on browser makers to implement the spec. Then someone creates a good polyfill to get the feature to work in said browser, and the pressure deflates. 

And that my friends is how an feature idea becomes a browser feature.

Now obviously I jest in some of this.  People aren’t always arguing or asking for rewrites out of revenge. All of the people in this process are passionate about what they do, and want to see things implemented in the web developer friendliest, most secure, most contingency meeting way possible.  But sometimes they are human beings who want to reduce their own work, follow their own agendas, and put browser maker concerns over browser developer, or browser users concerns. It’s human, it isn’t malicious, and a lot of time noise will make them do the right thing.

So my friends, when you ask “When will this feature be in browsers?” and I say, “I’m not sure” here’s why. 

Embedded with the Web Platform Team – Questions?

For two weeks, I’m embedded with the Web Platform team here at Adobe.  What does that mean?  It means, I’m acting like I’m part of the team, going to all the scrum meetings, taking a (very small) bit of work off their hands, and trying desperately not to screw anything up. 

For those that don’t know, the Web Platform team at Adobe is the group responsible for writing the specs, implementing the code, and shepherding the technologies that make up Adobe’s contributions to the W3C and WebKit. If you’ve seen our work on  CSS Regions, CSS Exclusions, CSS Shaders, CSS Compositing, or CSS Transforms then you have seen the fruits of this team’s labor.  I’m embedded with a subset of that larger group – the engineers that actually write the code.

I’m going to post some of my first week observations tomorrow or Monday, but I figured I’d put things out to you guys. Is there anything you’d like to know? Any part of the process that you’d like more insight into? Anything that you’d like investigated or answered while I’m here?

And don’t worry, the team might be in your browser rendering your coolness, but I will not be. The work I’m doing is all HTML work that will be run by the browser.  So no worries.

HTML5, Browser Lab, Typekit and New Design

I just got done with a site redesign. I had a few goals:

  • Fool around with new semantic HTML 5 elements
  • Use web fonts for typography
  • Do some jQuery for interactivity
  • Do a proper mobile version

Semantic HTML5
It seems like such a geeky little thing, writing header instead of div id=”header”, but I was shocked at the improvement it made. Much fewer divs made the HTML code so much easier to read, and so much easier to detect an improperly closed div.