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.

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.

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.

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. 

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:

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.

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!

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 Hoyt, Mihai 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

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. 

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.

Please follow her on twitter, and welcome her to her new role.

My current workflow with PGB goes something like this:

• Push changes to PGB
• Leave PGB open in browser tab
• Get bored
• Wander away to other browser tabs
• Remember that I am working on a mobile app
• Go back and check PGB
• See that it has updated
• Pick up device
• Click download link
• Reinstall

It’s not the best workflow.  Yeah, I could fix it by being more disciplined. But evidence suggests that’s not going to happen. I could solve my problem with technology. PGB has an API for answering questions like “Is the Android version of my app currently built?” So I put together a little mobile app to take advantage of that API. I call it PhoneGap Build Watcher. It does what you would expect:

• You enter your PGB credentials
• You get a list of all of your projects
• You choose one
• Any time that project gets updated you get sound, vibration and notification alerts.
• From that alert you can click on the download link and install the new version of your application.

This has really helped my workflow with PGB, and I hope some of you out there can use it to do the same.

See it in action:

It’s of course Open Source and hosted on GitHub.

I’ve put it up on Google Play, but was unable to get it into the App Store.  I should have realized it before trying but Apple doesn’t like applications that prompt you to download applications. No worries. Great thing about PhoneGap apps, they’re just web apps, so I have a web app version running at http://pgbwatcher.com if any iOS users want to give it a try.

Let me know what you think.

The difficulty with that is ANT doesn’t notify you when it is done.  Sure it prints a message that it’s done in the terminal window, but unless you’re looking there, you’ll never know. I stumbled on an easy way of getting notifications that are flexible and easy to work with on OS X:

The say command

In OS X, go to your command line and type 

say hello

Your Mac should respond in creepy robotic tones “Hello.”

You can get it to say anything… Okay, get all the immature juvenile tricks out now. My personal favorite:

say "I've got the collywobbles."

Okay. You can make it say anything, so you can make it say:

say “I’m done uploading all of your files to the website.”

So make an ANT task like: 

And join it with another ANT task like:

Call them both from an ANT task like:

And there you have it. ANT with notification. Creepy creepy robotic notifications.

What I like about this over say, sound effects, is that this method allows me to label specifically what each notification means, which helps if I run a few concurrent processes.

Don’t get me wrong. I love PhoneGap Build.  I love not having to open multiple IDEs to work on mobile apps. I love working on HTML apps in HTML tools – but you lose a few things in the trade. You lose being able to click one button and have your work available on your device.  You miss being able to click and get a pop up that says your work is ready to view on the device.

These things seem small, but having tried to build actual projects in PhoneGap Build, I found them critical.  I would go kick off a build, and then have to wait for the build to be complete.  I’d open a browser windows while I waited. 20 minutes later, I would cycle through my Chrome windows and remember that I was waiting for a build to complete.  

A few months back I tried my hand and solving this and came up with a shell script that handled this for Android.  Over the past few weeks, I’ve added to, improved, and modified it. I now have a solution in ANT that does the following:

• Uploads files to PhoneGap Build triggering a rebuild
• Polls for IOS and Android to be finished
• Downloads ipa and apk files when ready
• Installs them onto connected iOS and Android devices
• Uses the “say” command to let you know when things are done.

It takes the form of an ANT build file, some properties, and 2 shell scripts. I’ve posted the whole thing as PhoneGap Starter Productivity on github. As far as I know this will only work on OS X, which I hope isn’t a huge problem for anyone, and I’m willing to collaborate with someone to make them more cross platform friendly.

Also I feel it’s important to note, that while these scripts mean you don’t have to use the IDE to accomplish these tasks, you still have to have Xcode and the Android SDK on your machine to use them. 

I’ll be talking about Using PhoneGap Build to simplify your mobile development life. One of the great things about PhoneGap is that it allows you to use HTML JS and CSS to build your applications, but you still have to use native tools to build your apps. PhoneGap Build helps immensely with this, but you make some productivity sacrifices. This session will show you how to maximize your work, and touch as little of the IDE as possible. 

First time for me at this conference, but from what I understand it’s a great conference that tackles a specific topic: getting development and design to work together better. Great goal, really looking forward to it.

D2WC
May 16-18
Kansas City Marriott Country Club Plaza
4445 Main Street
Kansas City, Missouri 64111
USA