A new tool for designing Responsive Web Design websites

My dear reader please welcome the first public preview of a new tool for designing Responsive Web Design websites called Edge Reflow (part of the Creative Cloud offering). While many of you might have seen this tool presented at one of the Create The Web events we’ve been doing for the past four months, this release marks the first time anyone can actually download the tool and give it a try.

edge_reflow_mn

Before doing this I just want to add that this preview has some work ahead before it will get a 1.0 status. This is a good thing because we can work together and make sure that the final product will actually help you build better websites – your feedback is valuable and it will be taken seriously. Continue reading

How to use the CSS Regions Polyfill

We are really interested in getting your feedback on the CSS Regions Polyfill. So I thought that having a simple example to get you started with this JavaScript library could only help :).

This post assumes that you know what the CSS Regions proposal does and you have a basic knowledge of its syntax. If you don’t know this, maybe you should first read this tutorial.

1. Download the polyfill

Obviously, this is the first step. You can get the code from here (just look for the big green Download button). Save the archive on your computer and unzip the file.

2. Create a new HTML file

Next, create a new HTML file and include the cssregions.js file from the root of the archive. Note that there is a minified version too. But if you want to take a look at what the code does it is more convenient to use the non-minified version.

[code]

<!DOCTYPE html>
<html>
<head>
<title>My first example</title>
<script src="cssregions.js"></script>
</head>
<body>

</body>
</html>

[/code]

3. Add some content to act as the source of the regions

This short example is based on Chris Coyier’s example. I’ve just simplified the original example a bit to make it more readable.

First save this archive on your computer, unzip it, and then copy the ads folder to the same folder where your HTML file is stored.

Next add this code to your <body> tag:

[code]

<div id="my-source">
<a href="#"><img src="ads/1.jpg"></a>
<a href="#"><img src="ads/2.jpg"></a>
<a href="#"><img src="ads/3.jpg"></a>
<a href="#"><img src="ads/4.png"></a>
</div>

[/code]

We will use my-source id to define a name-flow called myregion. As I said this will be the source of our regions.

4. Add DOM elements that will consume the content

Now right before the <div> you copied earlier on, add this code:

[code]

<div class="page-wrap">
<section class="main-content">

<div class="article">Lorem ipsum dolor sit amet…</div>

<div class="ad-region-1"></div>

<div class="article">Lorem ipsum dolor sit amet…</div>

<div class="ad-region-2"></div>

<div class="article">Lorem ipsum dolor sit amet…</div>

<div class="ad-region-3"></div>

</section>

<aside class="group">

</aside>

</div>

[/code]

This is a simple markup that sets a main content area and a side bar on the right side. Notice that there are four empty DOM elements (<aside> and three divs with a class name starting with ad-region-). These elements will provide the regions that will hold the content retrieved from the div element with the ID “my-source”.

5. Add the CSS for defining the name flows and region chains

Now, it is time to add the CSS for defining the myregion flow. Copy this in the <head> section of your page:

[code]

<style>

* {
margin: 0;
padding: 0;
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}

body {
font: 15px/1.4 sans-serif;
}

.article {
margin: 0 0 30px 0;
}

.page-wrap {
width: 80%;
margin: 0 auto;
background: #eee;
overflow: hidden;
}

.main-content, aside {
padding: 80px 20px 20px 20px;
}

.main-content {
float: left;
width: 70%;
}

#my-source {
display: block;
-adobe-flow-into: myregion;
}

aside {
display: block;
-adobe-flow-from: myregion;
float: right;
width: 30%;
}

[class^=’ad-region’] {
display: none;
height: 155px;
width: 100%;
-adobe-flow-from: myregion;
}

#my-source img { /* the selector is always the source, not the element it flows into */
width: 100%;
max-width: 200px;
height: auto;
float: right;
margin: 0 0 10px 0;
}

@media (max-width: 800px) {
.main-content [class^=’ad-region’] {
display: block;
}

.main-content [class^=’ad-region’]:last-child {
height: 300px;
}

aside {
display: none;
}

#my-source img {
float: left;
width: auto;
margin: 0 10px 10px 0px;
}

.main-content {
width: 100%;
}
}

</style>

[/code]

This might look scary but it isn’t that scary actually. It uses media queries to turn on/off some of the regions used for laying the content. The same media queries are used to display or hide the side bar depending on the width of the page.

This is how the page looks when the width is greater than 800 pixels:

reg1

And here is the same page at about 350 pixels:

reg2

Now, the important CSS bits are:

[code]

#my-source {
display: block;
   <strong>-adobe-flow-into: myregion;</strong>
}

aside {
   display: block;
   <strong>-adobe-flow-from: myregion;</strong>
   float: right;
   width: 30%;
}

[class^=’ad-region’] {
   display: none;
   height: 155px;
   width: 100%;
   <strong>-adobe-flow-from: myregion;</strong>
}

@media (max-width: 800px) {

.main-content [class^=’ad-region’] {
   display: block;
}

aside {
   display: none;
}

}

[/code]

This is where the region chain and flow name are defined and different regions are showen or hidden depending on the page width.

You can download a ZIP file with the complete example from here.

Give us feedback

If you find issues or you need improvements, or maybe you want to contribute to the project, or you just want to share a cool example you’ve built using this polyfill make sure you tell us.

There are a number of ways to do this: add an issue on the GitHub repo, send me an email (see  the About section of my site for address) or just fork the repo and send us a Pull Request.

How to write a polyfill

Last week we made the CSS Regions Polyfill public. I thought it would make sense to share the experience of creating this JavaScript library as this was my first Polyfill. Thanks to the process we used I think it went pretty well.

Planning the work

Before writing a single line of code I’ve spent a lot of time reading the spec over and over again making sure that I had a good understanding of what this CSS proposal was all about. I also started to look at a bunch of examples so I could visualize what you can do with CSS Regions.

To be honest, after all the reading I was really overwhelmed. I realized that this was going to be really tricky as this feature is complex.

Fortunately, I wasn’t alone. Catalin Grigoroscuta and Alan Stearns helped me to distill a list of examples that were using CSS Regions.  Catalin and Alan did a great job selecting examples that were among the less complex and most relevant to what people would want to get out of CSS Regions. As you know, when you have a really complex problem to solve, often the best strategy is to break that problem into a number of small problems and solve the smaller problems one by one.

We started with only four or five examples. The first one was really simple; the rest were more and more complex. Looking at the list I was confident that it is could be done and done fast.

Once we had a baseline for what the MVP (minimal viable product :D) of our polyfill should be, I started to work. We deliberately avoided setting the matrix of supported browsers and browser versions beforehand. It was quite obvious that this polyfill would be quite heavy on the CPU so we needed all the help we could get from modern browsers in order to get decent performance for most common use cases.

Executing the plan

If you look at the CSS Regions spec through the eyes of a polyfill maestro you find two big problems to solve: parsing the CSS to find the DOM elements that are part of a region chain definition and writing the algorithm that “flows” the content between each region’s DOM elements.

Again my task was easier because my colleague, Razvan, had already put together a CSS parser for CSS Regions. While this parser wasn’t perfect (it didn’t support external style sheets for example) it was a great boost as it allowed me to focus exclusively on the flowing algorithm. And to make things even easier, the first example I started to support was Chris Coyier’s demo – this example flows only four pictures between a maximum number of four regions.

By the end of the day I had the first example supported so it was time to focus on the project infrastructure for a bit. We decided to use GitHub for this project. So once I created the project structure I created a new repo and uploaded the code. GitHub not only gave us the versioning support you need for any project but it gave the rest of the infrastructure with minimal pain: a Wiki, a place to track issues/bugs, a page for the project, and so forth.

After this first milestone was completed, it was only a matter of supporting the next example from the list. And with each new supported example the polyfill had more and more features supported from the spec: support for flowing Text Nodes and Images, basic support for CSS OM, support for external style sheets, and support for more browsers.

Setting up the project for supporting external contributors

For a while I was the only one coding. Then Razvan joined me as we needed a better CSS parser (supporting external style sheets, fixing some bugs, and so forth). This was when we decided that we needed a build system in place so if we could keep the whole project manageable as more people joined the project.

So Razvan took the lead here and set up a build process (using Grunt) that builds (and minifies) theJS file of the polyfill from four different JS files (each one holding a specific functionality of the project). He also created the first unit tests for the project using Qunit and and Testem. We added tests for the CSS parser, for the flowing algorithm, and so forth. This gave us a lot of confidence when we needed to change different parts of the code. And it provided us with the ability to accept code from external contributors.

Conclusions

Both Razvan and I had a number of different tasks to handle on top of this project. For example, I was travelling to more than a dozen conferences around the world while working on this project. This means I was on and off the project many times during a week as I was taking on more pressing things (preparing a session for the next conference, for example or traveling to and back from that conference). I think that splitting the problem to solve a number of relatively simpler problems helped us a lot with our busy schedule.

Also by using a lean approach by deliberately deferring everything that wasn’t mandatory for that particular project stage helped us to maintain a high development speed. And in my experience, good progress is one thing that can give wings to any developer.

Finally, I want to thank Vincent Hardy for giving me the opportunity to work on this project. I had lot of fun and learned new things while doing it.

Note: If you don’t know what a Polyfill is, check Remy Sharp’s post on this topic.

Brackets: How to add a new option to the menu

My first (and only one so far argh) commit to Brackets was about adding support for deleting the current line or current selection by using a shortcut. Once the Brackets team was OK with my code they suggested me that I expose this in the “Edit” menu as well to help with the discoverability of this feature.

To my surprise it took me a little bit more time than what I anticipated to achieve this. So, I decided to write this post. I hope that this will save you some time when you want to add something to the menu.

The first step is to create a variable that will hold the string that will be displayed in the user interface. Brackets has support for internationalization and because of this there are a number of files that are used to store this information. However the first place where you should add your string (and create the variable) is the default language file which is stored in scr/nls/root/strings.js. Open this file and add a new variable (make sure the name is unique) and set its value to the string you want to have in the UI. In my case this is what I’ve added:

[code]

"CMD_DELETE_LINES"   : "Delete Line(s)",

[/code]

If you want to provide translation for some or all other supported languages, all you have to do is to open the other files (eg. src/nls/fr/strings.js) and add the same variable name but with the translated string.

The second step is to create a unique ID for your command. I will tell you in a second why you need this. To do this, you’ll have to open the src/command/Commands.js file and create a new variable that has to have a unique value. For the sake of keeping things neat and clean, try to group your variable with others that have the same context. For example my command is displayed in the Edit menu, so I created the unique ID under the EDIT group of commands:

[code]

exports.EDIT_DELETE_LINES  = "edit.deletelines";

[/code]

The third step is to register your new command with the menu and assign a shortcut. This is where you’re going to use the unique ID you’ve created earlier. Open this file src/command/Menu.js and add a new entry to the menu section you want to update. I want my command to be available under the Edit menu, so this is where I added:

[code]

menu = addMenu(Strings.EDIT_MENU,
AppMenuBar.EDIT_MENU);

menu.addMenuItem(
Commands.EDIT_DELETE_LINES,
"Ctrl-Shift-D");

[/code]

Notice that the second parameter is used to set the command keyboard shortcut. You have to pay attention when choosing the shortcut so that it does not collide with an existing one. Also note that although the shortcut says Ctrl-Shift-D in reality on Mac it will be Cmd-Shift-D.

The final step is to register your command with the editor. This will bind the menu entry, shortcut, and the function to be executed when the command is executed together. Open this file src/editor/EditorCommandHandlers.js. At the end of the file you will see a block of CommandManager.register() calls. Just add a new CommandManager.register() call with the first argument being the variable that holds the label to be used in the menu. The second argument is the unique ID of your command, and the third argument is the function to be executed when the command is executed via the Menu’s option or shortcut:

[code]

CommandManager.register(
Strings.CMD_DELETE_LINES,
Commands.EDIT_DELETE_LINES,
deleteCurrentLines);

[/code]

If you’re wondering where the deleteCurrentLines function is defined, the answer is src/editor/EditorCommandHandlers.js.

This is it. Not that complicated isn’t it?

Playing with Adobe Edge

Recently, we released Adobe Edge preview 5.1 (you can grab the bits from here). Adobe Edge helps you to create interactive web sites and web animation using just HTML, CSS, and JavaScript. The tool does a really good job of being intuitive. Look at the image below:

You have the web page loaded on the canvas (Edge uses WebKit to render web pages), you have the timeline at the bottom, and on the right side you have a panel with all the HTML DOM elements from the current page. Here is a screenshot of an interactive design created with this tool:

I know there are some people who don’t trust visual tools that create web pages. But I encourage you to take a look at this tool and also give us feedback to make it better (Edge was downloaded by a large number of people, a clear sign that the tool answers a need many people have). If you are not able to visualize code like Neo,  a tool that helps you to code visually is simply awesome :)

There are many more things that the tool can do and as we move on towards the launch day more features will be added. If you want to check all the features that Edge supports, make sure you take a look at this page. If you prefer watching a video, here is the link. And if you want to see some cool sites created with Edge check this  link or this (if this isn’t enough check the Facebook page).

Continue reading

Using PhoneGap Build and Debug

PhoneGap is a great solution for building mobile applications for multiple platforms using the “write once, run everywhere” paradigm. However there is a tricky part: when you want to package your app and get the native installers you get back to the native development nightmare.

Typically you package your PhoneGap app using the developer tool chain for the specific platform. In other words, if you want to package your app for iOS and Android you will be using a Mac and XCode for iOS and Eclipse with Android plugins for Android. As you add more platforms you can get a sense of the magnitude of the problem.

This is exactly the problem PhoneGap Build solves. Using PhoneGap Build you can let the “cloud” do the crunching task for you. So from the comfort of your browser you only have to upload your application files (HTML, CSS, JavaScript, and images files) and PhoneGap Build will give you back installers for:

  • iOS
  • Android
  • BlackBerry
  • webOS
  • Symbian

Windows mobile support is coming in case this question was about to land in the comments section :)

Before moving on I want to stress one thing so I make sure you get the awesomeness of this service: in order to use it and get the native installers you don’t have install anything – no IDEs or developer SDKs.

Introducing Adobe Shadow – a new way to debug mobile web sites and apps

So what is Adobe Shadow? Shadow helps developers who work on mobile web sites and applications by enabling them to do “synchronous browsing”. You connect your mobile devices to your computer and then you navigate to a page on your computer and all the devices are synchronized displaying the same web page.

So when you open an URL in your desktop browser, all the connected devices will stay synchronized displaying the same URL. Furthermore, you can open up a debug session with one mobile device and use Web Inspector to check the DOM as it was generated on that device, check the CSS properties for DOM elements, resources, and network calls.

It supports iOS and Android devices and it works on Windows/Mac OS computers using the Chrome browser.

Continue reading

Debugging web pages remotely using a PlayBook tablet

In  a previous post I explained how you can use weinre to remotely “debug” web pages that run on your mobile devices. If you are familiar with weinre then you also know its biggest limitations: no JavaScript debug support and CSS styles introspection.

Now there is no need to be sad if you happen to have a PlayBook device. If so, then you are back in business. What do I mean by that? I mean full access to Web Inspector/Developer Tools goodies while browsing web pages on the PlayBook tablet. Yes, including JavaScript debugging and CSS introspection.

A question or a doubt might pop in at this point … how this could this be possibly useful for developing web applications that run on mobile devices when Android and iOS devices have the greatest market share? Relax my friend, no need to lose your faith :D Because iOS, Android, and PlayBook default browsers are all based on WebKit. Although there are some differences between them I think they are close enough that you can get lots of value out of using the PlayBook device as the “debug” mobile platform. It also performs fine, at least today. I mean it is not too far off from the latest mobile phones or tablets.

So let me guide you through the steps you need to complete if you want to remotely debug web pages using a PlayBook.

Continue reading

Debugging Web Pages and PhoneGap apps on mobile devices

If you are a web developer chances are that Google Chrome Developer Tools, Safari Web Inspector, or a Firefox equivalent are your best friends when it comes to debugging web pages (check CSS styles, verify generated HTML, or debug JavaScript). Isn’t that great? I mean not so long ago we used to debug JavaScript using alert() calls.

Once you get used to these tools it is hard not to have them. And this is exactly what happens when you move to mobile web development. As you probably know there is no web inspector running on your iOS device browser.

How do you debug your web apps when running on mobile devices? The best answer to this question is using weinre (if you know a better way, please let me know).

Continue reading

Flex Mobile Development: skinning the ActionBar component

One of the important pieces of the Flex framework for mobile development is the ActionBar class. This class lets you create an application title bar with three distinct areas. Starting from left to right you can have a navigation area, a title area, and an actions area. Of course you are not forced to use all these areas.

Why would you want to use this component? There are many reasons for using it but probably the most important is that it is an established user interaction design pattern on Android and iOS. This is how you usually add things like an application or section title, navigation buttons, search input texts, or action buttons.

Continue reading