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. 


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:

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. 


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.


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. 


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. 


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.  

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

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.

Using CSS Regions as an Enhancement

If you were not aware of them CSS Regions are proposal to CSS3 that would allow for some magazine like layouts in HTML pages. Adobe has been leading the charge on getting them into WebKit.  They are currently available in Chrome. (Also I think IE10)

Now the way they work:

  • You create a bit of content in an element like an article
  • You designate that article as the source of a “flow”
  • You designate other elements as the recipients of the “flow” (We’ll call them “regions”)

Then when the browser renders the content

  • The element designated as the “flow” is not shown
  • The content of the “flow” pours into the “regions”

Assuming this HTML:

And this CSS:

You get something like this:

I have a demo. It only works in Chrome.  Resize the screen to see the flowing of the content.

I was presenting on them the other night and I got asked a pretty good question.

Have you thought about how these degrade?

I made a bad joke, then mumbled something about if the browser doesn’t support CSS Regions then the original “flow” element gets displayed and all is well.

I tested it today. And all is not well. Because I still created those region elements. And they show up down at the bottom and add whitespace.

Check out the demo on any browser bu Chrome and you’ll see what I’m talking about all the way at the bottom.

So after some experimentation I decided that the best way to handle this was to create my four regions with CSS exactly how I had but only inject the region holders if the browser supports regions, like so:

Here’s a demo of the improved version.

In this case, I get a much better experience for non Chrome users–no weird mile of whitespace at the bottom of the content.

April NYC JavaScript and HTML5 Hackfest Meeting

I’m headed up to New York on Wednesday April 11 at 7pm  for the April meeting of the NYC JavaScript and HTML5 Monthly Hackfest. I was originally intending to just attend but I got tapped to do a 15 min talk.

I’ll be speaking about Adobe’s CSS contributions to Webkit, specifically Regions and Exclusions.

If you’re in NYC, it’s a great group so come on and check it out. Sign up on their site to find out the location details.

webDU 2012

Hello antipodeans and antipodiphiles, I will be speaking at webDU 2012 in Sydney, Australia in a few weeks.  If you have never heard of webDU, it is an absolutely fantastic web conference. It provides a great environment for honest open conversations and learning about the field.

I’ll be giving two talks:

Semantic HTML5

A foray into the geekier elements of internet HTML plumbing.

The Future of HTML5 Motion Design

Talking about Adobe Edge, and showing off some of the cool things we are doing with browser technology.

If you’re in the area, check it out.

May 3rd-4th
Sydney, Australia

MoDevUX 2012

It looks like I’m going to be speaking at MoDevUX outside Washington, DC later this month.

I’ll be talking about how to make great user experiences in mobile applications with PhoneGap.

It’s a new event and group for me, and it looks great. It’s a UX and UI focused conference with a focus on mobile.  Better yet, here it is in their words:

MoDevUX will bring together leading mobile developers, UX/UI designers, architects and managers to break the mold on user experience and design.  Attendees will discover the latest in mobile UX/design methods and meet likeminded people at the edge of the mobile frontier. Be sure to check out the workshops available on the 19th and the hackathon on the 21st!


If you’re in the DC area, check it out.

April 20
McLean, VA

HTML Page Slide Without a Framework

I’m working on a little demo mobile application for an upcoming project, and I wanted to add sliding transitions between pages. Pretty simple, right? You just use jQuery, jQuery Mobile, zepto, or one of a bunch of other frameworks, and they handle this for you. I didn’t want to.  Part of my goal with this particular project is to challenge myself to work without a framework so that I can see how this stuff works by hand.  Also I wanted to keep the HTML as slim and uncrufted as possible

Googling found very little to go on – except a micro solution for page transitions by FASW. I like it, but it’s still using someone else’s work, and I didn’t like adding even the little bit of HTML cruft that it needed.

So I rolled my own.

The solution I came up with actually is pretty lightweight and is powered by a little AJAX, some CSS transitions, and CSS transition events. It’s also important to note that this only works with WebKit. (My personal use case is for a mobile application with PhoneGap targeting Android and iOS, so I only need WebKit compatibility.)

First thing is to set the CSS of the body to have a transition on it, so when I move it around it’s animated.

Next thing I do is fire off a function when the page loads to replace all links with a function that will create the effect.  I use some techniques I learned from a great article named From jQuery to JavaScript: A Reference to handle these operations without jQuery.

Next step is to use AJAX to get the linked page.

Now comes the transitions.  What I need to do to accomplish this page slide is:

  1. Slide the page off the screen to the left.
  2. Instantaneously move the page to the right side off screen
  3. Replace the contents of the body with the new content
  4. Slide the page on to the screen from the right.

I have to do it in that order.  If you replace the contents independent of the animation, you get weird effects like the page changing then the animation happening, which looks jarring. Or you get the opposite, the transition happening, then the contents changing.  Looks ugly.  Trying to time these proved problematic. The best thing to do would be to wait for the transition offscreen to happen, then change the content, then move it back on screen. I was able to do this by using a transition event.

Basically as far as I can tell there is only one transition event “transitionEnd” regardless of browser manufacturer.  I haven’t been able to figure that out. Animation events appear similarly limited.  So here’s how I did it:

I moved the body to the left side of the screen.

There is an event listener that handles making it transparent while I move it to the other side of the screen.

I then replace the content, make it visible again, adjust the browser history, and move it back to the center.

Then to be thorough, I make sure that I reverse the process if the user hits the back button.

Is this the best way to do this?  I have no idea.  But it works for me and I couldn’t find a comparable solution via Google.

There is a demo here.(WebKit browsers only)

Full source code is available via github.

Search, Hold the Server

Being a content site, it was pretty important that have search–which was pretty hard considering that I didn’t want to have any server-side components involved.

At first I thought I would just let Google index the site, and hook up a Google search box on the site to solve the problem. That was certainly an option.  I thought I would have to do some SEO magic to make it happen correctly, but it was doable. In fact, Ray had solved this problem already.

But then I got to thinking, wouldn’t be cooler to rise to the challenge of a search without a server? Why, yes, yes it would. I broke up my needs into two parts:

  • An index of the site’s content
  • A mechanism for searching the index and displaying the results.

I kicked around a few ideas, but finally settled on the idea of creating a JSON file that had an array of objects with title, url, summary, and condensed content info. If I had such a file, all I would have to do is search through the JSON to find results. So the second part of my search was a snap.  All I had to do was:

  • Pull down the JSON file
  • Run searches against that JSON file
  • Present the results

All of this was pretty easy to do, and not revolutionary.

The difficult part was making the index in the first place.  The added difficulty is that I wanted to use JavaScript for everything.  So I couldn’t just use a shell script or some other easy way of indexing the files. Basically I wanted to remove barriers to entry, so an OS X shell script would create an obstacle for Windows based HTML developers to get involved.

Trying to do this with JavaScript in a browser was very hard. While there is a File API for the browser, you can’t use it to point at arbitrary directories on the file system like the site itself, you can only really point it at a sandboxed space. This made indexing kinda impossible.

I said I had to use JavaScript; but I didn’t say I had to use a browser. Enter Rhino the Java interpreter for JavaScript. Rhino gave me the ability to call Java File IO classes from JavaScript.  This allowed for easy indexing of the content. Now this might be a bit of a cheat since I am basically calling Java, which is a decidedly server-side technology in this case.  I rationalized my way out of it. ANT is required to build the project, but knowing how to fire off an ANT build and being forced to right full Java are two different things.  I’d love to hear if any of you are put off by this.

Rhino gave me the ability to run JavaScript from the command line, or from ANT.  Since we publish whatever gets checked in to the github repository, and we publish that code through ANT, I could just reindex as part of the build whenever new content comes in. New content causes a reindex, the index is always up to date, and generated on my terms – only JavaScript.

What it actually does:

  • Reads in all HTML files in the site
  • Filters ones that I don’t want in search results.
  • Grabs the title, url, and content from each
  • Writes out this content to JSON on disk

It’s not perfect. Search is pretty primitive – I don’t know how far it will scale. But for now, I have a pretty cool solution to my problem.

Here’s the indexer code: