Thursday, July 25, 2013

Introduction To Photoshop Scripting

By 

Automation is useful in the work of every designer. It saves precious time on repetitive tasks and helps us solve certain problems more quickly and easily.
You can automate your workflow in Photoshop with actions, which are pretty popular and which most of you already know about and use. Today, we’ll introduce you to an advanced automation technique: scripting. All you need for this is basic knowledge of JavaScript, which some of us Web designers already have.
I’ve known about Photoshop scripts for years but decided to really dive in a few months ago. I had avoided it because I thought it was the domain of smart math-minded programmers. I was wrong, and today I’ll show that, although it requires some basic programming skills, scriptingisn’t hard to grasp.
But first, we have to answer the obvious question.

Why Do We Need Scripts?

Why should we would learn to script if Photoshop already has pretty nice actions? The answer is interactivity. When you use an action, you can’t really control how it behaves in different situations; it is like a videotape that just keeps playing again and again without any change.
Why We Need Scripts?
A script is more dynamic; its behavior changes according to the parameters you input or the context of its application. Sounds useful, no?

Requirements

You don’t have to be an advanced programmer to be able to write scripts; I’m just a graphic designer, like most of you. But you should at least have a basic understanding of JavaScript and some experience with properties and methods to get the most out of this article.
Requirements
If you are not familiar with JavaScript at all, fear not! There are plenty of places to learn the basics of programming. Codecademy, for example, has pretty neat interactive lessons.
I work in Adobe Photoshop CS5, but everything we’ll cover applies to newer versions, too; Adobe hasn’t made any major updates to its scripting API since CS5. I will refer to the latest version of the scripting documentation, though, which is CS6.

Getting Started

When you record actions in Photoshop, you set the order of the steps to achieve a certain result — that’s your algorithm. Then, you press “Record” and replicate them in Photoshop one by one. Scripting is similar, but instead of doing these steps in Photoshop, you write them down as lines of code. Most actions that you do in Photoshop have their own script equivalent as a function.
Start here
Let’s say you are creating an action that scales a document to 150% of its original size. You’d go through these steps:
  1. Open Image → Image Size.
  2. Enter 150% in width and height.
  3. Hit “OK.”
The same process with a script would look like this:
  1. Call the application: app
  2. Target a document: activeDocument
  3. Call the function to resize the image: resizeImage(width, height)
And the code would look like this:
app.activeDocument.resizeImage("150%", "150%");

LANGUAGE

There are three ways to write scripts for Photoshop: using AppleScript on Mac, VBScript on Windows or JavaScript on either platform. I use the third because it is cross-platform and I already have some experience with it.

TOOLS

Adobe has its own utility for writing scripts, called ExtendedScript Toolkit.
Adobe ExtendedScript Toolkit
The main window for Adobe’s ExtendedScript Toolkit. (View large version.)
The toolkit comes with Photoshop, and you can find it in the following folder:
  • Mac OS X
    /Applications/Utilities/Adobe Utilities CS6/ExtendScript Toolkit CS6/
  • Windows
    C:\Program Files\Adobe\Adobe Utilities - CS6\ExtendScript Toolkit CS6
    (or Program Files (x86) for 64-bit machines)
The user interface of the ExtendedScript Toolkit is pretty straightforward. To start writing scripts, first select the target application in the drop-down menu. If Photoshop is running, then look for the green chain icon near the drop-down menu:
Application Select
Now you can write something like this:
alert("Hello Photoshop!");
Press cmd + R (or just hit the “Play” button in the toolbar) to run your script. ExtendedScript Toolkit should switch to Photoshop and show an alert box:
Hello Photoshop!
ExtendedScript Toolkit has some other neat features for debugging scripts, but this is enough for this article. You can learn more about how to use it by going to Help → JavaScript Tools Guide.
You can use any plain-text editor to write a script; just save it as a .jsx file. To run it, you’ll have to go to File → Scripts → Browse in Photoshop and select it. Alternatively, just open the script file with Photoshop. You can also add a line of code at the top of the script so that the file always opens in Photoshop:
#target photoshop
Save your scripts in the Photoshop/Presets/Scripts/ directory, and access them with File → Scripts. You can also set up a hotkey; just go to Edit → Keyboard Shortcuts, navigate to File → Scripts → [your script’s name], and set the shortcut you want.
ExtendedScript Toolkit can run and debug code from the integrated development environment, and it has an object model viewer built in, which is useful. So, I recommend using the toolkit to write your scripts. Unfortunately, the Mac version crashes sometimes, so keep that in mind.

PHOTOSHOP OBJECT MODEL

To make writing scripts easier, you should understand how things relate to each other in Photoshop’s Document Object Model (DOM). Understanding it is not so hard if you look at Photoshop itself. The main object in Photoshop’s DOM is the application. In the application, we have a collection of documents that are currently open in Photoshop.
Each document contains elements — such as layers (called ArtLayers), groups of layers (LayerSets), channels, history states and so on — just like in a regular PSD document.
A simplified visualization of Photoshop’s DOM is below. A more detailed containment hierarchy can be found on page 12 of “Adobe Photoshop CS6 Scripting Guide” (PDF).
Simplified visualization of Photoshop API
A simplified visualization of Photoshop’s DOM.
Each of these objects has its own properties and methods that you can work with. For example, to change the opacity of the selected layer in a document, you would go toApplication → Document → Layer → Opacity and set the desired value. The code would look like this:
app.activeDocument.activeLayer.opacity = 50;
As you may have guessed, activeDocument and activeLayer determine the currently selected document and layer.
You can find descriptions of most objects and their properties and methods in “Adobe Photoshop CS6 JavaScript Scripting Reference” (PDF), or in ExtendedScript Toolkit by going to Help → Object Model Viewer.
Let’s see how this works in a real-world example. In this next section, we’ll write our own script based on an action.

Remastering The RotateMe Action As A Script

A few years ago at Christmas time, I had an idea for an action to help me draw snowflakes.

DRAWING SNOWFLAKE 101

  1. Draw one stem of the snowflake with a pattern.
    Step One
  2. Duplicate the stem, and rotate it a few degrees.
    Step Two
  3. Repeat the second step until you have a full circle.
    Step Three
Duplicating and rotating each stem manually is tedious, so I came up with an action to automate it. The algorithm looks like this:
  1. Duplicate the stem.
  2. Rotate it by however many degrees you’ve chosen, using the Transform tool.
  3. Duplicate the layer.
  4. Use the “Repeat Transform” function.
  5. Repeat steps 4 and 5 until you have a full circle.
Pretty neat. But the action had a disadvantage: You can set only a certain number of stems for the snowflake, according to the number of degrees you set in third step of the algorithm.
Back when I wasn’t familiar with scripting, I just made a few versions of the action, each of which produced a snowflake with a different number of stems.
Today, we will remaster this action as a dynamic script that takes your input on the number of stems. Let’s get started!

ALGORITHM

When you start writing a script, defining the algorithm first before digging into the code itself is always a good idea. In our case, the algorithm will work like this:
  1. Ask the user to enter the number of stems.
  2. Calculate the rotation angle.
  3. Duplicate and rotate the layer by the number set in the first step.
Let’s start with saving the current or selected layer to a variable for further use:
// Save selected layer to variable:
var originalStem = app.activeDocument.activeLayer;
Note that in JavaScript, you can mark a line with double slashes (//) to make it a comment. Comments are used to describe parts of code for future reference and don’t affect the behavior of the script.
Let’s move on to our algorithm now.

1. ASK USER FOR INPUT

We can take input from the user with the prompt(message, default value[, title]) function. This function shows a dialog box with the message and an input field that contains thedefault value. When the user hits “OK,” the function returns the inputted value; so, we have to save it to the variable to be able to be used.
// Ask user for input by showing prompt box and save inputted value to variable:
var stemsAmount = prompt("Processing \""+originalStem.name+"\"\nHow many stems do you need?", 12);
Note that I used originalStem.name in the message, so the dialog box will show the name of selected layer.
On Mac OS X, the first line of the message is in bold and functions as the title. So, our main message should be on the second line. To make a new line, type \n.
In Windows, you can specify a third argument in the function to set the title:
// Ask user for input by showing prompt box and save inputted value to variable:
var stemsAmount = prompt("How many stems do you need?", 12, "Processing "+originalStem.name);
If we run the code in Photoshop, it will show this dialog box:
Prompt dialog
When the user hits “OK,” the inputted value will be saved to the stemsAmount variable. If the user clicks “Cancel,” then the function will return a null value. We’ll use this later.

2. CALCULATE THE ROTATION ANGLE

To calculate the rotation angle, we have to divide 360 degrees (a full circle) by the number of stems:
// Calculate the rotation angle
var angle = 360 / stemsAmount;

3. DUPLICATE AND ROTATE

Now we have everything we need to make duplicates of our stem. To do this, we’ll use thefor loop. It lets us repeatedly run lines of code as many times as we’d like. Our loop will look like this:
for(var i = 1; i < stemsAmount; i++){
 // This code will run "stemAmount - 1" of times
};
Note that the first instance of an object in programming has the value of 0, but because our first layer is already on the canvas, we’re starting the loop from 1 instead.
To duplicate and rotate our layer, we will use the duplicate() and rotate(angle, AnchorPosition) methods: the number of layers to be rotated in angle multiplied by the indexed number of duplicates. AnchorPosition determines the point around which the layer will rotate. You can see this point when you use the Transform tool in Photoshop — it looks like a small circle with a crosshair. In scripting, it has only 9 specified values — i.e. the 9 positions of the anchor point:
AnchorPosition visualization
In our case, it is the bottom center of the layer, BOTTOMCENTER. Photoshop uses a lot of other constants here and there in some of the functions, which you can find on page 197 of “Adobe Photoshop CS6 JavaScript Reference” (PDF).
So, our loop will look like this:
// Duplicate and rotate layers:
for(var i = 1; i < stemsAmount; i++){
 // Duplicate original layer and save it to the variable 
 var newStem = originalStem.duplicate();

 // Rotate new layer
 newStem.rotate(angle * i, AnchorPosition.BOTTOMCENTER);
};
And the completed code will look like the following. You can try to run it.
// Save selected layer to variable:
var originalStem = app.activeDocument.activeLayer;

// Ask user for input by showing prompt box and save inputted value to variable:
var stemsAmount = prompt("Processing \""+originalStem.name+"\"\nHow many stems do you need?", 12);

// Calculate the rotation angle:
var angle = 360 / stemsAmount;

// Duplicate and rotate layers:
for(var i = 1; i < stemsAmount; i++){
 // Duplicate original layer and save it to the variable
 var newStem = originalStem.duplicate();

 // Rotate new layer
 newStem.rotate(angle * i, AnchorPosition.BOTTOMCENTER); 
};

FINAL TOUCHES

I’ll usually try to achieve the main goal with a script, and when everything works correctly, I’ll start to refine the code. In our case, we have to make sure that the user inputs a valid number in the prompt box — i.e. a positive integer, greater than one.
Also, to prevent Photoshop from going crazy, we will restrict the number of stems — let’s say, to 100. To do this, we will use a while loop to show the user an error message in the event of an invalid submission, and the prompt box will continue to be shown until the user enters a valid value or hits the “Cancel” button (remember that the prompt returns null if the user hits “Cancel”).
The new code looks like this:
// Save selected layer to variable:
var originalStem = app.activeDocument.activeLayer;

// Ask user for input by showing prompt box and save inputted value to variable:
var stemsAmount = prompt ("Processing \""+originalStem.name+"\"\nHow many stems do you need? (From 2 to 100)", 12);

// Check that user entered a valid number and, if invalid, show error message and ask for input again
while(isNaN(stemsAmount) || stemsAmount <= 0 || stemsAmount > 100){
 // If user clicks "Cancel" button, then exit loop
 if(stemsAmount == null) break;

 // Show error message…
 alert("Please enter number in range from 2 to 100");
 // …and ask for input again
 stemsAmount = prompt("Processing \""+originalStem.name+"\"\nHow many stems do you need? (From 2 to 100)", 12);
};

// Run the copying process
if(stemsAmount != null){ 
 // Calculate the rotation angle
 var angle = 360 / parseInt(stemsAmount);

 // Duplicate and rotate layers:
 for(var i = 1; i < stemsAmount; i++){
  // Duplicate original layer and save it to the variable
  var newStem = originalStem.duplicate();

  // Rotate new layer
  newStem.rotate(angle * i, AnchorPosition.BOTTOMCENTER);
 };
};
As you may have noticed, we’re using the isNaN(value) function, which returns true if valueis “not a number” and parseInt(value) to convert the value to an integer when we calculate the rotation angle.
The next thing we will do is manage the layers, renaming our new layers by adding an index to them. Also to make sure that we do not mess up document’s layers, let’s place our stems in a group.
Renaming the layers is not a hard task. We will just use the name property of the layer and add an index number to it:
// Add index to new layers
newStem.name = originalStem.name + " " + (i+1);
A group in Photoshop’s API is called a LayerSet and we can access all groups of the document by calling the layerSets property. To add a new group to a document, we have to call the layerSets’ method add():
// Create a group for stems
var stemsGroup = app.activeDocument.layerSets.add();
 stemsGroup.name = originalStem.name + " ("+stemsAmount+" stems)";
Then, to add a layer to the group, we will use the move(relativeObject, ElementPlacement)function. Note that the move() function moves a layer in the layer stack, not on the canvas. (You can move a layer on the canvas with the translate(deltaX[, deltaY]) function.)
ElementPlacement is another constant, this one determining how we will place our layer relative to… well, relativeObject. In our case, we will use ElementPlacement.INSIDE to place the original layer inside a group:
// Place original layer in group
originalStem.move(stemsGroup, ElementPlacement.INSIDE);
We will place each new copy of the layer at the bottom of all layers in the group usingElementPlacement.PLACEATEND. The result is all of our layers arranged in ascending order, the first layer at the top and the last at the bottom:
// Place new layer inside stems group
newStem.move(stemsGroup, ElementPlacement.PLACEATEND);
You can read more about the ElementPlacement constant on page 202 of “Adobe Photoshop CS6 JavaScript Reference” (PDF).

Final Code

That’s it! RotateMe.jsx is done. Our final code looks like this:
// Save selected layer to variable:
var originalStem = app.activeDocument.activeLayer;

// Ask user for input by showing prompt box and save inputted value to variable: var stemsAmount = prompt ("Processing \""+originalStem.name+"\"\nHow many stems do you need? (From 2 to 100)", 12); // Check that user entered a valid number and, if invalid, show error message and ask for input again while(isNaN(stemsAmount) || stemsAmount <= 0 || stemsAmount > 100){ // If user clicks "Cancel" button, then exit loop if(stemsAmount == null) break; // Show error message… alert("Please enter number in range from 2 to 100"); // …and ask for input again stemsAmount = prompt("Processing \""+originalStem.name+"\"\nHow many stems do you need? (From 2 to 100)", 12); }; // Run the copying process if(stemsAmount != null){ // Calculate the rotation angle var angle = 360 / parseInt(stemsAmount); // Create a group for stems var stemsGroup = app.activeDocument.layerSets.add(); stemsGroup.name = originalStem.name + " ("+stemsAmount+" stems)"; // Place original layer in group originalStem.move(stemsGroup, ElementPlacement.INSIDE); // Duplicate and rotate layers: for(var i = 1; i < stemsAmount; i++){ // Duplicate original layer and save it to the variable var newStem = originalStem.duplicate(); // Rotate new layer newStem.rotate(angle * i, AnchorPosition.BOTTOMCENTER); // Add index to new layers newStem.name = originalStem.name + " " + (i+1); // Place new layer inside stems group newStem.move(stemsGroup, ElementPlacement.PLACEATEND); }; // Add index to the original layer originalStem.name += " 1"; };
That wasn’t too hard, was it?
Finish
Now you can put it in the Photoshop/Presets/Scripts/ folder and run it by going to File → Scripts in Photoshop. Using different shapes with different values can yield interesting results:

Conclusion

As you can see from the number of links in the resources section below, there’s much more to say about scripting than can fit in an introductory article. But I hope the little that we’ve described today piques your interest and shows how powerful and helpful scripting is.
Community Power!
If you decide to dive into it, let’s learn together and share our experience. Ask your questions and share what you’ve done in the comments. If you are not a coder, consider leaving an idea for a script; maybe another reader will make it happen.
Let’s make Photoshop more useful together!

RESOURCES

I’m still learning about Photoshop scripts, too, and here are some resources that are helping me along the way:
  • “Adobe Photoshop Scripting,” Adobe Developer Connection
    All of the documentation and utilities for scripting.
  • “Adobe Introduction to Scripting” (PDF), Adobe
    Here are the basics on scripting for Adobe applications. The nice thing about scripting for Photoshop is that you can apply your knowledge to other Adobe products; you just need to learn the application’s DOM, and you’ll be ready to go.
  • “Adobe Photoshop CS6 Scripting Guide” (PDF), Adobe
    In this introductory guide to scripting for Photoshop, you’ll find the basics on getting started with scripting.
  • “Photoshop CS6 JavaScript Reference” (PDF), Adobe
    This describes all of the objects and their functions and methods that you can use in scripting for Photoshop. This is one of the documents I use most when writing scripts.
  • “JavaScript,” Mozilla Developer Network
    Here are answers to all kinds of questions about general JavaScript functions and usage.
  • “JavaScript Tools Guide” (PDF), Adobe
    This has basic information about ExtendedScript Toolkit and some advanced techniques, such as file system access and ScriptUI and working with XML, sockets and more.
  • PS-Scripts
    An independent forum about scripting for Photoshop. I haven’t signed up to participate in discussions, but it has plenty of answered questions and solved problems to discover.
  • Photoshop Scripting, Adobe Community
    Adobe’s official forum for Photoshop scripting has some good discussion on problems encountered by users.
(al) (ea)



via Smashing Magazine Feed http://www.smashingmagazine.com/2013/07/25/introduction-to-photoshop-scripting/

Karen McGrane on Content: Douglas Engelbart and the Means to an End

Go to article

 · Published in User Experience, Interaction Design, Usability, Workflow & Tools ∙ 2 Comments
Seventy years.
ENIAC, the world’s first programmable digital computer, was completed in 1944. Today, more people have access to mobile phones than have access to toilets. There are more mobile internet users in the developing world than in the developed world.
It took just seventy years to get from a device the size of a two-story building to a device that fits in your pocket. Seventy years to build a browsable, searchable archive of information, accessible globally. Seventy years between a time when research and data was locked up in books, available to only a privileged few, and a time when information and communication could be obtained by everyone, everywhere.
I am awestruck by this human accomplishment. It’s no secret that I am a huge nerd for computing history. I’m inspired both professionally and personally by the fact that this transition happened within my lifetime—that I, in a sense, was at the revolution, and I got to witness and participate in these societal changes. I try to share my enthusiasm for the recent history of technology because I want the names of the men and women who made this happen to be remembered. I hope 500 years from now, people talk about Douglas Engelbart the same way we talk about Johannes Gutenberg.

The bootstrapping strategy

Engelbart passed away this month, and his obituaries cover the facts: his research was the precursor to many of the innovations that led to the rise of personal computing. If you want to reduce his work to easily understood “features,” you can point to hypertext, to multi-window displays, to video conferencing and shared screen collaboration, or yes, the mouse. Bret Victor summed up this facile interpretation, saying:
This is as if you found the person who invented writing, and credited them for inventing the pencil.
We don’t always have a good way to summarize the impact of new technology based on its desired effect. What was the goal of movable type? What was the point of the steam engine? What was the intended societal outcome of electricity? Fortunately, Engelbart tells us what his intent was in developing these technologies—they were a means to an end.
His point wasn’t to build a pointing device. His goal was to help humankind expand its capacity to solve problems:
The complexity and urgency of the problems faced by us earth-bound humans are increasing much faster than are our aggregate capabilities for understanding and coping with them. This is a very serious problem; and there are strategic actions we can take, collectively. Consider a community’s “Collective IQ” to represent its capability for dealing with complex, urgent problems—i.e., to understand them adequately, to unearth the best candidate solutions, to assess resources and operational capabilities and select appropriate solution commitments, to be effective in organizing and executing the selected approach, to monitor the progress and be able to adjust rapidly and appropriately to unforeseen complications, etc. I contend that a strategy for “facilitating the evolution” of our organizations’ Collective IQs will be the optimum approach, aka a bootstrapping strategy.
Each generation has its own vision for the purpose of new technology. A wartime ambition of machines calculating ballistics trajectories gave way to Vannevar Bush’sMemex and J.C.R. Licklider’s Man-Computer Symbiosis, which in turn gave way to more recent perspectives on what personal computing, the internet, and mobile are good for. You can’t understand Engelbart’s vision without understanding it in relation to other schools of thought—and your understanding of our current point of view might be enhanced by seeing his perspective.

AI vs. HCI

In the 1960s it was assumed that we would one day welcome our new artificial intelligence overlords. The mainstream of computer science believed that robots would soon do our thinking for us; the interim period where we might partner up with the machines and use them to do our bidding was seen as a mere blip in the history of technology.
Engelbart’s view of the future of computing in the sixties ran directly counter to the precepts of the mainstream of the computing business. The era was dominated by a belief that artificial intelligence was at hand and would soon create a world populated by thinking machines. Engelbart’s notion of creating work groups where human intelligence was instead “augmented” by computers was thought of as quaint and beside the point.… Indeed, Engelbart’s augmentation philosophy was in many ways the polar opposite of artificial intelligence, which sought to replace humans with machines.
John Markoff, What the Dormouse Said
Humanity’s role at the center of this equation wasn’t a given—in fact, it was a crackpot theory, at best only useful for the interim 15 or 50 years we needed to make artificial intelligence a reality. But because Engelbart insisted on viewing computers as a tool to make us smarter (and not on using us as tools to make smarter robots) we have a field that is, at its core, focused on the user’s experience. If I had to give him credit for something, I’d pick that over the mouse.

Ease vs. power

No one talks about the chord keyboard.
Engelbart’s vision of computing technology included many features familiar to us today—and also included a three-button mouse and a five-button chorded keyboard, both intended to be used in concert with a traditional QWERTY keyboard.
That’s a lot of buttons to learn. Engelbart was okay with that.
Today, the highest praise you can give an app is that it’s “intuitive.” We aspire to develop touchscreen interfaces so simple, a two-year-old could figure them out.
The pendulum has swung about as far as it can toward the consumerization of computing technology, in which everything should be immediately intuitive and nothing should require learning, training, or practice. Engelbart’s vision was on the opposite end of that pendulum swing—he believed that the power of these tools came with inherent complexity.
We benefit from ease of use, but we also benefit from the power that comes from learning complex interactions. If I had to pick one philosophy of Engelbart’s I’d love to see make a comeback, it would be a focus on developing learnable tools aimed at expert users (but maybe not the chorded keyboard.)

Augmenting human intellect

Each generation takes existing technology as its due and uses it to achieve some further aim. We’re not beholden to Engelbart’s goals any more than we’re limited by a vision of computers used solely as calculating machines.
I once taught a course in computing history in which I asked the students whether they thought we had achieved Engelbart’s vision of “augmenting human intellect” through the personal computer, the internet, and now mobile. Opinions were mixed, citing:
  • The completeness and incompleteness of Google search in returning results that span the whole scope of publishing
  • The effectiveness and ineffectiveness of the internet in helping us form more well-reasoned arguments
  • The upside and the downside of using computing technology for social, gaming, and other entertainment pursuits
It’s easy to feel paternalistic about the mobile internet, the promise of education and research in the hands of people who have never had easy access to information. And it’s easy to be disappointed by statements like “In a lot of foreign markets, people think that the Internet is Facebook.”
Engelbart recounts reading Vannevar Bush’s article As We May Think in a Red Cross library in the Philippines during World War II, and how this article inspired him decades later. Decades after Engelbart’s work, we can be inspired by his vision of “augmenting human intellect,” but also see it from a new vantage point, as the mobile internet makes information available to billions more people. Engelbart used technology to “bootstrap” the problem-solving capacity of his research lab, connecting people to enable them to do collaborative work. Today, the problem-solving capacity of humanity has exponentially expanded by connecting people globally through the mobile web.
We also might see the next Engelbart emerge from somewhere in the the developing world, browsing the mobile web from a $30 phone. I hope, in my lifetime, I also get to see this next great innovator, informed by access to the internet, enabled by the mobile web, inspired to create the next new vision for what technology can do for humankind.

Wednesday, July 24, 2013

New Hotel Booking Site Stayful Has Us Hopeful (So Long As Our Bid Gets Accepted)


July 22, 2013 at 5:29 PM | by  | Comment (1)
UPDATE 7.23.11: The recommend bid of $190 for The Nolitan Hotel was denied. Back to square one we guess.
Being hotel nerds determined to get the best deal on our hotel rooms, we've been known to get a little obsessive with all the hotel booking sites out there. We once rounded up our 5 favoritebooking sites to use and we're not lying when we say we usually consult all of those sites before booking a hotel room. And now we'll be adding one more into the mix--Stayful.com.
Stayful.com was just announced last week as a new booking site for independent boutique hotels, and not for every random chain hotel brand under the sun as you often see on most booking sites. But Stayful is not as wide-open as other booking sites. For starters, the site is in beta right now and is invite-only. And it's also only offering hotels in San Francisco and New York. So if you were looking to book that Chicago getaway, you'll just have to sit tight.
But Stayful does have one cool feature that most other sites don't usually have--"Bid or Book It Now." As the name suggests, you can search hotel rooms and either bid a lower price than what's listed or book it now and get the best available rate. If you're unsure about what to bid (and perhaps to prevent people from bidding too low), Stayful gives guests "recommended bids" which are rates that their site's algorithm believes the hotel is most likely to accept. Aha, finally some guidance in the hotel room bidding realm. That said, you can enter your own bid but you can only enter one bid per hotel every 24 hours.
According to Stayful folks, the independent boutique hotel industry loses $13.9 billion in revenue each year due to unsold hotel rooms. Cheryl Rosen, co-founder and CEO of Stayful, who previously worked at Expedia, Hotels.com called the Bid or Book It Now function of Stayful the "missing piece" in the online travel world
“There are thousands of independent boutique hotels around the world and they’ve struggled to find new customers for their unsold inventory. On the other side, travelers often don’t realize that they aren’t getting the best prices through existing sites. With Stayful, they’ll choose their own unique hotel experience and choose exactly the price they want to pay.”
So how do the rates and suggested bids stack up against the competition? We plugged in dates for August 1-3 on Stayful for New York and the following came up:
The site is true to its mission to feature independent boutique hotels, with the exception being the Trump Hotel at Central Park. But the "recommended bid" prices were about $50 less than the instant reservations prices. That's pretty good. We especially liked The Nolitan for a recommended bid of $190 versus the Book It Now price of $249 for a Neighborhood Queen Balcony.
So we clicked on the Recommended Bid button to see what would happen. Almost instantaneously, we received an email from Stayful telling us that the bid was sent to the hotel for review. After 24 hours, we would receive a note telling us whether the hotel accepts it. From then, we have three hours to make the decision if we want to book the hotel or not. Here's the email wording:
Please allow at least 24 hours for a response directly from Stayful. Our partner hotels typically respond very quickly because we're helping them sell rooms that may have gone unoccupied, which is why our members are able to get excellent rates.
Meanwhile, over at Expedia, The Nolitan was going for $245 a night for the same room type. The Nolitan's own website was offering $292 for a fully pre-paid rate for the same room type. If our Stayful bid gets accepted, then we will have saved nearly $100 off the hotel's room rate. Score!
If you're in a hurry and need a room fast, clearly, this site is not for you. But if you like the idea of bidding or negotiating for your room and can't stand the opaque-ness of other sites (like Priceline and Hotwire), not to mention the hassle (raise your hand if you're bid has been denied a few times on Priceline) then Stayful is going to make you gleeful. And hopefully, lead to a gleeful hotel stay as well.



via HotelChatter - http://www.hotelchatter.com/story/2013/7/22/165353/258

Client Relationships and the Multi-Device Web

by MATT GRIFFIN 

Published in Business, Mobile/Multidevice, Responsive Design, Project Management ∙ 19 Comments
When you step into the room with a client, you are a visitor from the future. You, web professional, spend your days immersed in the new paradigms of the multi-device web. Yet even for you, the constant change and adjustments that come with living on the internet can feel overwhelming. So how do you think your clients feel?
The web is fluid and mercurial. Our processes for working with it—and our clients—need to reflect that. It’s time for us to shed the vestigial mindsets we’ve inherited from the advertising world—the closed communications and drama of the “big reveal”—and build new systems based on honesty, inclusion, and genuine communication. We can bring our clients into the process right away, letting them see all the flaws and bumps along the way. Through this relationship they will become true partners—rather than confused, anxious bystanders—as we learn to better navigate this strange, evolving digital universe together.

Perspective is everything

When your clients first think of a website, the mental image they conjure is likely that of a web browser as rendered on a desktop computer. This is completely understandable—after all, the majority of their website experiences occur while sitting at desks, fiddling with the things sitting atop those desks.
From where we’re sitting, however, we see the web as comprised of many more devices. Until recently, it’s been convenient to think of those devices as belonging to definable buckets like “smartphones,” “tablets,” and “laptops.” But as more and more varied devices have entered the market, those buckets have multiplied and overflowed, giving way to an amorphous continuum of display sizes, resolutions, browsers, operating systems, conventions, and interface possibilities.
This has required an overhaul in our thinking. Rather than websites being a series of perfect constructions rendered on each screen in exacting detail, web designers have started thinking in terms of systems. Flexibility has become a more valuable currency than specificity.
If your clients have ever been part of a traditional design project before, this is not what they’re expecting to encounter in your meetings. So how do we begin bridging this gap? How do we help our clients start seeing the internet through our magic design goggles? For heaven’s sake, how do we talk about this stuff?

HOW DO I EXPLAIN THIS INTERNET?

There are three big components to acclimating the uninitiated, which I think of as the three S’s: statistics, stories, and specifics.
Statistics are great because they can quickly make a point about the urgency of a matter. For instance, when speaking with clients about the importance of mobile markets, I often refer to this statistic:
42 percent of smartphone owners between the ages of 18 and 29 consider their phone as their primary way of accessing the internet (from Pew Internet).
Client: What? 42 percent? That’s berserk! We had no idea mobile was so important! Now what do we do?
That’s the power of statistics. They don’t give a lot of context or provide any kind of holistic understanding of a problem, but they do turn heads and introduce a need. A hard-hitting stat is a terrific way to begin a conversation like this.
Stats sure can make a point, but humans are social and emotional creatures. To make ideas memorable and help them stick in one’s craw, it can be helpful to reach for a personal story that exemplifies the issue, making it more tangible. Comme ça:
I have a three-year-old son. And as you may or may not be aware, three-year-olds left to their own devices are incredibly adept at finding new ways to injure themselves. That means that when I’m at home and I need to look up something on the internet, I can’t just run upstairs to the attic to use my desktop computer. But I do have another computer (my iPhone), handily located in my pocket. Now, I’m on the couch at home—I’m not what one would typically describe as a “mobile user,” but I am on the most mobile device there is, and I expect the same quality of user experience and access to information as I would on my desktop. When I’m at home—my phone is my computer.
See how that worked? Now my statistic supports a narrative. My story has characters, a setting, and an (admittedly simple) plot. It’s more engaging than a PowerPoint slide with convincing stats on its own, and now my clients are more likely to incorporate this idea into their view of the internet. When they begin to think of “mobile users,” hopefully the image of Matt Griffin on the couch absorbed in his iPhone while being manically circled by a pajama-clad toddler will enter their brains, along with our old friends Guy in Line at Grocery Store and Woman Waiting at Bus Stop. Paradigm: shifted!

SHOW, DON’T TELL

“But wait,” you say, “there was a third S!”
Excellent, you are a very astute reader and have passed the first test. Let’s talk specifics. Specifically, which specifics? Glad you asked!
If what you’re used to is a tiny, multi-column site on your iPhone, and pinch-and-zoom is standard procedure, you may look at your first responsive site and wonder where everything is. Where’s the navigation? Where’s the sidebar? Where’s all the stuff?
I find that a useful exercise is to simply pull up a responsive site on my phone and hand it around the room, while I resize the same site on the projector or TV that I’m using for the presentation. Clients can see that the main navigation collapses into a hamburger icon. The sidebar moves down below the main page content.
Watching this interaction on the big screen while they reproduce it on a handheld device helps everyone to make that connection between the mobile and desktop experiences. They can see that the content isn’t disparate, just recontextualized.
Demoing a few sites like this in the kick-off meeting (particularly well-known brands like Starbucks and Paravel’s Microsoft homepage) helps to reinforce that responsive design is a growing standard that users likely expect to see on your client’s website as well. After all, if some of the world’s most established consumer brands have already taken the plunge, it will feel a whole lot safer for your clients.

Delivering the deliverables

Helping your client be more aware of responsive conventions will provide the context necessary for them to give you better feedback on your design work. But first, you need to show them which deliverables they’ll be reviewing, and let them know what sort of feedback will be useful for each one.
For responsive designs, we’re finding that smaller, more focused deliverables coupled with frequent client feedback get us on the right track more efficiently.

GET IT IN WRITING

We start every project with a short, written specification that includes project goals, feature descriptions, site information architecture, a site map, and a branding profile. For a recent project Bearded worked on with the Andy Warhol Museum in Pittsburgh, we kept everything in a text document on Basecamp, where it was editable (and version-controlled) by everyone on the project. That helped us update it quickly, without misleading, out-of-date versions floating around. Version control also made sure that we had a record of any changing decisions, should they come into question later.
The specification document spells out the goals and strategies for the project. It’s the victory list and the game plan.1
Getting an early version of this document into your clients’ hands is essential. Make sure each and every stakeholder knows how important this is, and has read it and given their thoughts or concerns before you continue. I suggest a message like this:
Participating in the writing of the specification document now means your ideas will be incorporated into the final product. Please make sure anyone that needs to weigh in later reviews this document. Let them know: if the outcome of this project is important to you, we need your feedback on the spec doc by next Friday!
Often these suggested edits spark new conversations about what’s important to accomplish on the project. If someone’s idea for a feature or approach sounds off-base to you, ask why they think it’s crucial. How does it relate to the project goals? If it doesn’t, do you need to revise the goals, or does this stakeholder just need to be reminded of the big picture?
Once these key plans are in place (and everyone on the team is finished making edits), we have what we need to start getting visual.

FRAME YOUR WIRES

To define page layout accurately and efficiently for responsive design, the browser is the place to be. For the Warhol Museum, we built this responsive wireframe. It came out of our front-end starter kit, Stubble, and took about two and a half hours to put together. It’s not pretty, and that’s the idea. No one’s going to mistake this for a website design. But they will understand that these are the first steps toward defining information hierarchy and layout.
When we show our clients wireframes, we ask them for content-oriented feedback:
Are we missing any important chunks? How about the relative importance of the chunks that are there? Does this seem like the raw information this page needs?
At this stage we’re trying to make sure we have all the stuff we need on the pagebefore we start designing it. But just because we’re still working out the page content, doesn’t mean we can’t also dabble in aesthetics.

WHEN LO-FI IS THE BEST -FI

Wireframes are great at being wireframes, but they don’t do squat for look and feel. Somewhere between a style prototype and a traditional page mockup, a lo-fi mockup embodies web design pragmatism—efficiently conveying the overall tone. We quickly assembled this lo-fi, static mockup as a companion piece to the Warhol wireframe.
With these lo-fi mockups I tell our clients to ignore the details for now, and give us feedback on the broad strokes:
We all know this isn’t a website yet. But is it going in the right direction? If it’s not even close, why? Is it too casual? Too professional? Not on-brand? If it does feel “in the ballpark,” great. We’ll keep moving in this direction, knowing you’re on board.

MAKE YOUR FEEDBACK A LOOP

The granularity of your client’s feedback should match the level of detail of the deliverable they’re looking at. So lo-fi visuals get lo-fi feedback and sign-off. Let’s look at a common reaction:
Client: Hmm. The mockup feels a little stuffier than I thought it would.
Me: In the spec doc we said we wanted it to be both sophisticated and playful. Maybe this isn’t playful enough? Should we try to dial back the stuffiness and get a little more weird?
Client: That sounds about right. What are you thinking?
Me: I’m not exactly sure what that looks like yet, but I do think the interactions we create later will be a chance to have more fun. Why don’t we see what we can do now—maybe revising the color scheme to be more energetic—then see what we can do to liven things up once we get in the browser. Sound good?
Client: Yep! Let’s do it.
You should adjust things until the group agrees that we’re “close enough,” but don’t sweat the details. It’s not the place for it. When you feel that twinge in the back of your mind that says, “We’re getting nit-picky,” that’s when it’s time to say:
We’ve got ourselves a solid foundation, is it OK to move on now?
Moving on, of course, means more detail. Less metaphor, more reality. That’s right, you guessed it: it’s time for some HTML/CSS mockups!

CONVERSATIONS, NOT REVELATIONS

In-browser comps are the full-on deal. Honest-to-goodness hi-fidelity interactive mockups using semantic, reusable HTML and CSS (as discussed in my previous article, Responsive Comping). After approving the wireframes and lo-fi comp, our client saw this mockup for the Warhol project.
Not only is it responsive, but it’s a significant evolution of the aesthetic presented in the earlier lo-fi mockup. It’s taken the spirit of the static mockup and the organization of the wireframe that everyone agreed on, and added a new level of refinement, detail, and polish—all right there in the code.
Any client feedback now will likely be pretty minor. Why? They’ve been participating in the whole process, guiding it to this point. They knew what to expect and weren’t surprised by what you presented. It’s the polar opposite of the “big reveal.” No drama—just a natural evolution toward an effective design solution.
Remember: each client request for a revision is actually a request for a conversation. My default response to any change is, “Why?” Help your client focus on the “why,” and remind them that figuring out the “how” is your responsibility. Focusing on “why” helps you address the root cause, rather than a possibly incidental symptom.

Now we can begin

Taking the extra time to help our clients understand the challenges we face and the role they’ll play in our process makes them easier to communicate and work with. It will help build their confidence in you, strengthen your rapport, and bring them more fully into your team for this and future projects.
It’s true that your new clients may not yet know and love this squishy internet the way you do. But enthusiasm is infectious. Help your clients see the internet for what it is (magic design goggles optional), and all your client interactions will benefit.

NOTES