…Hello Google

Starting December 1st, I’m going to be a Developer Advocate for Google Cloud Platform. It’s a similar role to what I’ve done before: go out to events or reach out online, and talk to people about technology that can help them. But Advocates are less about marketing than Evangelists, and more about product improvement. The idea is that while we’re out talking to people, we listen to their feedback and bring it back to the product teams. Evangelists do that too, but my gut feeling is that organizations with “Advocates” take that feedback much more seriously.

I’ll be talking about an awesome product. Or more accurately, suite of products. From Platform as Service and Virtual Machines to Storage, Databases, and Big Data queries, there is a lot to talk about, and lots of rabbit holes to wander down. I intend to wander down a few of them and bring you all along.

I’ll be talking to developers again, which is awesome. The past few years found me drifting further and further away from the developer communities that inspired me to get into this line of work 6 years ago. My work angst for the past 12 months and the work and projects I did to prepare for and secure this job made it very clear that this is what I really want to be doing.

I’m joining a team of intimidatingly smart people. And I do mean “intimidatingly” cause the interview process is as challenging as all the rumors make it out to be. But everyone I met along the process were incredible to interview with, and I can’t wait to start working with them.

I find myself reporting once again to Greg Wilson, and I honestly couldn’t be any happier about that. Good managers are both rare and more important than people think they are. When you find one, count yourself lucky, and if you can work for a manager you’ve confirmed is good, well, you do it.

Google culture encourages workers to informally collaborate. They find that keeping people in the same space yields better collaboration. And despite all of the advantages to working remotely I missed the serendipitous hallway meetings. So after 6 years remote, I find myself returning to daily commutes. I always said I couldn’t go back – but then again, when there is free Coke Zero, showers, nap pods, and brilliant co-workers – maybe it might be even better than working from home. I’ll miss seeing my kids the way I used to, but frankly, now that they’re in school, I don’t see them as much as I’d like to anyway.

You might be asking: Hey, does Google have an office in Philadelphia? Actually they appear to, but it’s not an office with any Cloud engineers. So my family and I are leaving Philadelphia for somewhere in the Bay Area, probably San Jose. This was not an easy choice, but I am very excited about the prospect. We’ll be around for the rest of 2014, with us moving in the beginning of 2015.

So let me finish by pointing out that none of this would be possible with out the encouragement and support of my wife, Janice. She was my practice interviewer, cheerleader, and sounding board. When the very people interviewing you point out that “Imposter Syndrome” is a huge part of the interview process, it’s hard to not to get lost in your head second guessing yourself. Janice was consistently convinced that I could get the position, and even helped me convince myself sometimes. And when I did get it, she agreed to move across the country to a place where we have no roots, with 2 children in tow. Not only did she agree to it, she embraced it for the opportunity it is. That doesn’t mean it isn’t terrifying for the both of us, but at least for me it is less so, ’cause she’s going to be by my side.

So there you have it, lots of change, I think they’re awesome changes, and I can’t wait.

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.

Little Update to Brackets Reflow Cleaner

reflow-brackets-workflow

I made a little update to Brackets Reflow Cleaner.  This is the Brackets extension that can extract information out of Reflow asset files and allow you to speed up developing designs created in Reflow.

Here’s an example:

 

I’ve added support for extracting gradient information in both colors, and its own location.

Check out my video to see what Brackets Reflow Cleaner can do.

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

Apache Config file support for Brackets

I’ve been doing a bunch of tweaking of Apache files on my development machine because I had to do some machine hopping.  In the course of doing that I found myself wishing there was syntax support for Apache config files in Brackets.  I looked; I couldn’t find it.  If I want it, I have to do it.  So I did.

brackets_apache

It’s pretty simple, considering that it is a CodeMirror Mode, and I don’t really understand how it all works.  It provides syntax highlighting for .conf files and .htaccess files.

Here’s the GitHub repository; if I get any interest I’ll add it to the Brackets Extension Registry. I’d love to get some other eyes on it to make sure I’m not doing anything colossally stupid.

Reflow Cleaner

reflow-brackets-workflow

Disclaimer: Reflow isn’t intended to be used the way I will layout, and this isn’t an official Adobe thing.  This is just me fooling around with some ideas. 

As a follow up to my post about what you do after you work with Adobe Edge Reflow, I’ve been exploring the source code Reflow creates looking to see what I can do with it. I’ve also been experimenting with Brackets to see if I could use that to deliver some workflow here.  My experiments have yielded the unoriginally named “Brackets Reflow Cleaner.”  It does what it sounds like, it cleans the output you generate with Reflow in Brackets into something approaching that which you would use in a hand coded HTML file. How does it work?

In Reflow, I use the ability to label parts of my design to indicate what I want things to be.  

reflow-cleaner-org-orig

I label things with element names to output them as elements.

reflow-cleaner-org-element

I add a period to the front of a string to mark it as a class.  

reflow-cleaner-org-classes

From all this I can create an outline that looks like my eventual HTML should look.

reflow-cleaner-org-all

Now Reflow doesn’t really care about all this as you can see by the HTML it outputs. It turns them into id’s.

reflow-cleaner-html-before

However, I have the HTML. I can run processes on it to convert it to something else.

reflow-cleaner-html-after

Now the CSS is a little different.  It is very verbose, full of ids, and crazy percentages. I’m not sure what to do with it.  But I can analyze it and maybe pull out some interesting details from it.

Color

reflow-cleaner-colors

Font

reflow-cleaner-fonts

Breakpoints

reflow-cleaner-css-breakpoints

I can even use the intelligence on the classes I setup in the Reflow file to analyze classes to figure out what was the same about them and create common classes for them.

reflow-cleaner-css-after

Here’s a video with a complete demonstration of it. 

I wrapped all of this up in a Brackets Extension so that if you wanted to play with it, you could. It’s Open Source and available on github. 

This is an experiment and a starting place.  I’d love to hear from anybody that give this a try.  Is it usable? Does it help you do anything.  Is this a crazy waste of time?  All opinions welcome. 

 

Reflow Gets Support for Regions

There’s bound to be a lot of excitement from my colleagues today about the awesome addition of CSS Regions to Mobile Safari and support in Adobe Edge Reflow and Adobe Edge Code. I share it, but I want to focus on the fact that you can start working with these features today in Reflow.  For the longest time, I’ve been talking to audiences about both our new tools, and our efforts with the W3C, but to be able to see them come together like this is awesome. 

The big question for regions is “how would I actually use it” and fooling around with it in Reflow allows you to answer that for yourself.  Where would you use it? Try it and see.  My answer: you use it where you need reflowable content that keeps a layout you want despite not being pixel stable. Let me show with this example.

Here is a screenshot of an article layout in Adobe Edge Reflow.  You can see I’ve laid the article out in several columns around a picture. 

regions1

The great thing about Regions is that those columns remain stable despite the contracting screen (as you can see in following screenshot).  I don’t have to worry about how the text will layout cause I’ve given it general instructions on how to do it.

regions2

But eventually that layout won’t work, those three columns will get too tight. No worries. Reflow allows me to make responsive decisions that really make my content layout correctly, but still allow me some variety in layout. 

regions3

And finally when the design just won’t work anymore, I linearize the content, and I have an article that is readable everywhere, but has magazine like layout where it make sense. 

regions4

Keep in mind that right now you’re going to be limited in using these features in Canary and Mobile Safari.  But I think our hope is that the more people that make compelling layouts with these technologies, the more browser vendors will see that this is tech that they want to include. So check it out on the Adobe Web Platform Blog, and create some awesome layout in HTML.  

Update:
If you want to fool around with the Reflow file I used in this example, here you go.

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.