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.

Photoshop Generator with Reflow

The newly released Photoshop Generator feature works awesome with Adobe Edge Reflow.  I used it to redesign my site. I was very happy and very productive.  However when I first launched this, I ran into an issue where it didn’t work the way I thought it was.  Basically I thought that the magic was miraculous instead of just incredibly cool.  When you first convert a PSD to Reflow you have to take a moment and organize the Reflow project before you start designing a set of responsive layouts. Once you get how Photoshop exports, it makes sense. But at first you have to do some work for yourself. I have a video showing how to do this. 

The video will also take you through adding Typekit support to a generated Reflow project.

Hope this helps!

Theseus – A Promising Reason to Use Brackets

brackets_iconFrom time to time, I show off Brackets, the Open Source HTML/JavaScript/CSS editor Adobe has been working on for the past year and half.  It’s a great bit of work, and it looks great. However, a lot of people point out that there are a lot of other code editors that can be used on HTML out there.  Which is is true – so let me show you a compelling reason to use Brackets: Theseus.

Theseus is a research project that brings debugging to JavaScript in the editor. Not just debugging, but crazy real-time debugging that’s easy to understand and jump right into.  Check out the explanation of Theseus over at the Brackets team blog. And then check out the GitHub repo.   Seriously, if you work with JavaScript, do it now – you won’t regret it.

Also, just as an aside, it turns out that Brackets is up for a Readers’ Choice Award from Linux Journal.  If you’re a fan please give it your support by voting for it.

Upgrade Creative Cloud to Creative Cloud for Teams

I was asked this week if it was possible to upgrade from an individual Creative Cloud account to a Creative Cloud for Teams membership AND get the discount for being a Creative Suite Customer. Added complexity? There are multiple accounts to upgrade. It appears to be possible, here’s how you do it.

Go to http://creative.adobe.com.

If you are logged in, log out.

cc-upgrade-logout

You should have the login screen. From that screen choose “Get Started”

This will takes you to the plans page, navigate to “Plans for Teams & Business”

Under Upgrade choose “Join.”

cc-upgrade-teams

You will be taken through the steps to join.

Enter the Adobe ID of the account that you want to be the manager of the whole team

cc-upgrade-account

You’ll be prompted to enter a serial number for to see if you qualify for upgrade pricing.

cc-upgrade-qualify

After your qualify you will have to go through the rest of the sign up.

At the end, your account will now have the ability to manage a team.

cc-upgrade-newoption

From this point on, you can now invite additional accounts.

cc-upgrade-invite

Hope this helps!

Facebook Chatheads in CSS

If you haven’t seen Facebook’s “chat head” interface, here is the quick lowdown. There are little circular icons that will float on the side of your mobile device’s screen to tell you that a message has arrived from a friend. It’s part of the Facebook Home thing, but even if you are on iOS, the Facebook App uses them.  I think this will be one of those UI things you either love or hate.

fb-ch-single

However, from an HTML angle, I thought they were interesting. Could you do this interface in HTML/CSS?  The answer is yes, and it is quite easy. Just some borders, border-padding and negative margin.

https://gist.github.com/tpryan/5486052.js?file=1.html
https://gist.github.com/tpryan/5486052.js?file=1.css
fb-ch-single-ss

Demo

That was relatively simple, but it gets more complex when you have a multi-person conversation. Facebook takes the most recent person in the thread and makes them take up half of the “chat head.” Then come the next two, taking up a quarter each.  Then the rest are hidden.

Okay, so I need to pull out of nth child magic to selectively style the first 3 items in a collection of images. Set overflow to hidden, play with some more border radii and BOOM, “chat heads” done.

https://gist.github.com/tpryan/5486052.js?file=2.html
https://gist.github.com/tpryan/5486052.js?file=2.css
fb-ch-multi-ss

Demo

Okay, so that’s all been pretty straightforward, so I’d like them to be interactive.  If I click on a multi-member conversation “chat head” I’d like it to expand out the rest of the members. This is very easy. Just a little JavaScript and some class swapping.

https://gist.github.com/tpryan/5486052.js?file=3.css
fb-ch-multi-x-ss

Demo

 

So done, Facebook native interface done in CSS/HTML.  But I think we can do better.  One of my issues about this interface and one that would prevent me from using it in a web based application is that it obscures the content beneath it, it just hangs out covering up anything unfortunate enough to be below it. For me, if I was using it I would want it to float instead of absolutely position. So I can do a few tweaks to make that happen. 

https://gist.github.com/tpryan/5486052.js?file=4.css
fb-ch-multi-x-float-ss

Demo

Now in my demonstration, I pulled the text to be right aligned instead of left aligned, to show the float edge better.  But I’m still not happy with it. Why? Because each of those circles carve a giant square out of the text. And that’s kinda lame because they’re circles.  A few weeks ago a colleague of mine at Adobe, Bem Jones-Bey wrote an article about using shaped exclusions from the CSS Shapes and Exclusion spec.  It seemed like a perfect fit.  So if you have Chrome Canary installed, and the experimental features turned on, you get a much different result:

fb-ch-multi-x-float-canary-ss

Demo [View in Canary]

The secret sauce here being the -webkit-shape-outside property.  It basically allows me to exclude a circle from the underlying text around each of the “chat heads”. To find out more about using shape-outside, be sure to check out Bem’s article. It’s just one of the ways that the browser is becoming more capable of rendering a greater number of visual layouts and effects.

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.