For Photographers, Instagram Square Photos are Worse than a TOS Update

Austin, Texas

I’m a photographer and I use both my iPhone 4S and my Digital SLR to take photos.

There’s a difference between taking pictures and taking photos, however, and the nuance is an important thing to understand. When you raise a camera and snap a photo, unless you’re paying attention to things like composition, lighting, depth of field, aperture, shutter speed and ISO, you’re taking a picture. If you’re doing all of those things (or reasonably close to all those things), you are safely in the category of “doing photography”.

One is casual. The other is intentionally art (whether good art or not is a subjective matter that shouldn’t be handled in this post).

Art doesn’t have to be Pablo Picasso or Ansel Adams or John Lennon. It doesn’t have to have a philisophical meaning or intent. Art is the expression of the Artist on an outward medium. Or in the case of photography, it is more simply the interpretation of what the eyes sees into a likeness in film or in digital media. Photography as art cannot be done haphazardly. That’s how people get caught in the trap of buying a $2000 camera and wondering why their photos suck. Because there is no context of movement, sound, smell or touch, the essence of a point in time must be captured entirely visually. If it’s done right, it’s art because care, intent and a degree of skill are needed to translate the moment into a snapshot.

Photographers work hard to get this right. It takes a perceptive eye, a knowledge of the equipment, lighting and composition to make a great piece of art in the form of a photograph.

I thought this was about Instagram?

This is about Instagram. Instagram’s app used to allow the user to upload a photo that did not fit a strict “square” format and pinch and squeeze to resize and get an entire photo in. While this was not as aesthetically pleasing as it could have been, it gave the photographer the ability to use the entirety of a photo and the composition nuances in it.

The new app does not allow for this zoom and strictly enforces a square model. The Next Web covers some of the pushback and takes the opposite side as me – that it’s high time Instagram enforce a square photo.

Take this photo as an example. I love this photo of Downtown Austin from across the S. Lamar St Bridge. The composition here is extremely important. The reflection of the bridge in the water, the trees and of course the kayaker under the bridge make this photo what it is. Here is my post-production piece.

Austin, Texas

However, what happens with Instagram? I have to scroll to one side or the other or find a happy medium in the middle for this photo.

Austin, Tx - iPhone

I realize, of course, that many users hate to see black bars across the top of the Instagram photo, as it was the day I posted my photo to Instagram!

Austin, Tx - Old InstagramHowever, this is the balancing act that Instagram has to consider. While creating a photography app for the masses, the need to keep photographers on board is essential. The new app takes away the artistic prerogative and choice from the artist and puts discretion in the hands of the masses. Last time I checked, the masses don’t shoot my photos, edit my photos, make artistic choices about my photos or have the same skills or style that I possess as an artist.

choose what my photos look like. I use Instagram to publish because it has two things: an audience and a distribution vehicle. When I post to Instagram, I push my photos to both Twitter and Facebook. I chose this even with the artistic limitations that it offered before this app update (namely the “letterbox” that goes with the photos that don’t fit into a square format).

One can argue that Instagram had to make a business decision, perhaps inline with the desires of their Facebook overlords. I guess that argument can be made. But removing artistic license abilities of artists who are using the platform is a terrible idea. Imagine if Twitter had said, back in 2007, that they had this platform that could only be used with 140 characters because it was built for use over text message and, since that was their original idea, and the colonial approach to the short message service was the only appropriate way of consumption, then text messages would be the only method of use allowed.

That is, in fact, exactly what Instagram has said indirectly, and what the Next Web article (linked above) advocates. Hey, photography used to be limited to a square format because it was the cheapest way to do it. Yeah… and then we got 35mm film which opened up a 4:3 ratio. And then we got digital that opened photographers to new technologies to create different formats, styles and use different concepts to create art.

Imagine if all our music sounded exactly the same way as the Beatles did in the 60s. Would there be any evolution to music? Of course not, because every artist would sound exactly the same way, use exactly the same cadence, write lyrics that epiphanize the exact same mindset that existed in the 60s and generally would be boring today – and I’m a big Beatles fan!

Returning to a square format is not a bad thing. There are vintage schools of thought in every format of art, fashion, music and culture. But that doesn’t mean that every artist should be forced to adopt such styles. That makes photography boring and conformist. That’s not why we do photography!

 

Contest: 3 free copies of the WordPress Bible [UPDATE]

Today marked the drop of WordPress 3.5 and I want to celebrate.

Tomorrow, I’m going to give away three autographed copies of the WordPress Bible. You have to be on Twitter. I apologize to those who have chosen to abandon Twitter, or have chosen not to participate, but it is the defacto communications medium of the 21st century and how I operate.

The book is a mix of advanced and beginner content. Therefore, I will do trivia. Trivia will have a beginner round, an advanced round and an intermediate round. All WordPress oriented. The winner is in my sole discretion and you will be required to provide your mailing address if you are selected.

WordPress core contributors are not allowed to participate in the beginner or intermediate round. If your name is on “the list” of 3.5 contributors, you cannot win those rounds. You can, however, participate in the advanced round.

The beginner round will consist of questions surrounding theme and plugin management with possible questions around usability and interface.

The advanced round (the only round open to core contributors) will be based on WordPress APIs, hooks and advanced WordPress development.

The intermediate round will mix both but the developer-oriented questions will be more common and basic and user questions will be more difficult.

You must hashtag your answers with #wpbibletrivia. Failure to do so disqualifies you for an answer.

The first answer I see that is correct is a correct answer. My judgement solely.

There will be 10 questions per round so pay attention.

The beginner round begins at 11am Central Time.

Share this on Facebook, Twitter or whatever your social media channel of choice is. The questions will be asked on my Twitter feed: @technosailor.

Good luck!

Update

The winners of the trivia contest were David Peralty for the beginner round, Kim Parsell for the intermediate round and Kailey Lampert for the Advance round. Well done, everyone!

Working With HTML5 Forms

html5

html5I’m going to start a series of tutorials over the next weeks and months about HTML5. A lot of web developers are not leveraging HTML5 for a variety of reasons. We have been so trained over the past decade to embrace XHTML 1.0 that we’ve avoided the new DOCTYPE as something new that needs to be learned.

The good news is, XHTML is still valid in HTML5. The better news is now you have much more fun toys to play with.

Admittedly, I was one of those people who delayed jumping on the HTML5 bandwagon. In the past few months, however, that has changed. This series of articles will hopefully help the web developer to rethink how they develop on the web. Much of the stuff I’m about to talk about does not require a lot of extra heavy lifting.

Use the Correct DOCTYPE

Just as a remedial exercise of laying out the premise, your HTML must have the correct DOCTYPE. In XHTML 1.0/1.1, the first line of the HTML page had to be something along these lines

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

That’s relatively confusing, huh? Makes you want to go drink spoiled milk with lumpy crud in it just because it’s tasty, right?

To declare a web page as HTML5, you do the same thing you did with the old 1990s era HTML4, before the web embarked on the XHTML idea of doing work. HTML5 is, essentially, a reset to HTML4 with all kinds of additional goodness. You simply start a web document with:

<!DOCTYPE html>

A lot easier, right? Heck, you can type that in your sleep once you’ve typed it enough (I know you already do that with your drivers license and credit card numbers).

Form Field Types

With all that remedial knowledge in play, let’s take a look at HTML5 forms. The importance of this might be lost if the only thing you think about, when building HTML pages, are computer browsers. But if you recognize we live in a mobile world, you own an Android or iPhone and have tried to do any kind of form filling on those devices, then you might start to realize the importance of field types.

In XHTML, you might have a form that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<form action="" method="post">
    <label for="name">Full Name:
        <input type="text" name="name" id="name" />
    </label>

    <label for="phone">Phone Number:
        <input type="text" name="phone" id="phone" />
    </label>

    <label for="email">Email Address:
        <input type="text" name="email" id="email" />
    </label>

    <label for="website">Web URL:
        <input type="text" name="website" id="website" />
    </label>
</form>

In XHTML, we didn’t have a lot of field types. We had text (which everything above is), hidden, password (*’s entered in the input), checkboxes and radio buttons. You could add other types of inputs (That don’t use the <input> tag and include <select> and <textarea>.

This works in HTML5 too, but you’re limited by one default keyboard – which is fine, but fairly bland and not at all contextual.

What would happen if we changed that form to use different field types? HTML5 support a bunch. The four fields above can more sematically have the following types, in order: text, tel, email, url.

Watch what happens on the iPhone when the HTML looks like this (Android is similar):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<form action="" method="post">
    <label for="name">Full Name:
        <input type="text" name="name" id="name" />
    </label>

    <label for="phone">Phone Number:
        <input type="tel" name="phone" id="phone" />
    </label>

    <label for="email">Email Address:
        <input type="email" name="email" id="email" />
    </label>

    <label for="website">Web URL:
        <input type="url" name="website" id="website" />
    </label>
</form>

For a standard text field, your keyboard will look like this:

iOS "text" field

iOS “text” field


For a phone number, using the tel type:
iOS "tel" field

iOS “tel” field


For an email address, using the email type:
iOS "email" field

iOS “email” field


And for a URL field using the url type:
iOS "url" field

iOS “url” field

There are, of course, other field types that I’m not going to go into too much here. But to whet your appetite, there is a color type that attaches to a color picker. There’s a date type that binds to a date picker. There’s even a range type which binds to a slider picker.

Important: Not all browsers support all types. In the event that a browser does not support a specific type, it falls back to standard text type and you can bind other external Javascript to make the same functionality happen.

Reference: All HTML5 field types with browser support.

Form Field Placeholder

Another useful feature is the placeholder. In XHTML, we might have a form that looks like this:

1
2
3
<form action="" method="post">
    <input type="search" name="search" id="search" value="Search for your term" />
</form>

This would create a simple field that would be pre-populated with “Search for your term”. From a usability standpoint, when a user brings that field into focus, the text is supposed to disappear and allow the typing of a search term. If nothing is typed and the focus is switched to a different element, then that phrase should re-appear.

XHTML Placeholder Text

XHTML Placeholder Text

You can’t do this without a little Javascript help (I like jQuery for this) – which is outside the scope of this article. But in HTML5, you only have to add placeholder="Search for your term". Different browsers handle this slightly different, but they all insert some dummy text that can be replaced by the user’s own input.

1
2
3
<form action="" method="post">
    <input type="text" name="search" id="search" placeholder="Search for your term" />
</form>
HTML5 Placeholder Attribute

On iOS, the Placeholder attribute plays light grey text in the field that is replaced as the user types.

Form Field Validation

Validation is such a tedious thing for developers. You can do all kinds of ugly things to make sure fields that are required actually have a value or that a field meets a certain criteria (for instance, a zip code field having 5 numeric characters to match the U.S. format).

In terms of requiring a field, it’s as simple as adding required to the input tag. In HTML5, you don’t have to have an explicit value for an attribute as you do in XHTML. You can if you want, type <input type="text" name="zip" required="required" /> but this is a habit that does not need muscle exercise. Just use:

1
2
3
4
<form action="" method="post">
    <input type="text" name="zip" required />
    <input type="submit" />
</form>

Firefox "Required" Error Bubble

Firefox “Required” Error Bubble

Chrome "Required" Error Bubble

Chrome “Required” Error Bubble

Browsers handle this differently but they all pop up a notice if the field isn’t populated on submission. On the right, you’ll see how Chrome and Firefox handle this respectively.

Let’s validate that zip code field, though, because this is where HTML5 really shines.

Using the pattern attribute, you can designate a regular expression to match formatting needs. If we want to limit the zip field to 5 numbers (most simplistic example – it could also have a potential extra dash and 4 numbers too), you might use this HTML:

1
2
3
4
<form action="" method="post">
    <input type="text" name="zip" required pattern="\d{5}" />
    <input type="submit" />
</form>

You can find a list of helpful regexes at html5pattern.com.

Summary

There’s a lot more we could get into here, but the point of this exercise is to prove that it doesn’t take much to start using HTML5 in development. Doing so will also push the boundaries of what has been more commonly possible and the barrier to entry is so low that I struggle to find a reason why HTML5 should not be used more commonly.

I’ll have more of these in the days and weeks to come so stay tuned, subscribe to the RSS feed and, as always, if you’re interested in hiring me for a full time gig or contract basis, please reach out to me. I am actively looking.