Using the Intel Developer Forum event this week, Intel lifted the vial on their new HTML5 Development Environment.

WordPress 3.6 is right around the corner, due to be released in early May. What can you expect from the next version of this popular blogging and CMS platform? A lot! This release’s underlying theme has been “Improving the Editing Process,” and a lot of attention has been given to user interface and workflow processes. Oh, and we also have a shiny new default theme to play with!

Let’s take a look at some of the features and improvements WordPress 3.6 will bring to your website…

Say Hello to Post Formats, Your New Best Friend

Post formats have been a bit of a hidden gem in WordPress. Not quite a post type in of themselves, they are instead more of a way of classifying posts in a way that is different from your standard category and tag taxonomies. They’ve actually been a built-in feature of WordPress since version 3.1, although in order to use them they had to be enabled by the theme. Also, the user interface was a bit on the kludgy side, and as a result post formats were underutilized and under appreciated.

WordPress 3.6 addresses these issues and makes post formats a whole lot easier to use. The radio button meta box has been replaced with a selection of the available post formats above the content editor field. When a particular post format is selected, any fields that it requires appear automatically; a URL field for the “link” post format, a “Select / Upload Image” button for the image one, etc.

WordPress 3.6 brings post formats front and center.

For theme developers, there are new template tags to help you take full advantage of the improved support for post formats. Functions such as the_post_format_video(), the_post_format_url() and the_remaining_content() will let theme developers pull the meta information from the post and apply a unique design treatment to each format.

WordPress themes will still need to support post formats in order to reap their extra benefits, of course, so don’t expect legacy or abandoned themes to take advantage of them. As existing themes are updated and newer themes are developed, post formats will become a much more important piece of the theme landscape.

Speaking of Post Formats…

One of the more popular post formats is video, and WordPress 3.6 makes working with video easier than ever before. When you choose a video post format and enter a URL from a popular video hosting service, WordPress 3.6 will automatically embed that video into your site. You read that right. No more plugins just to embed your favorite YouTube “cat falling into water” video.

What’s more, that video will be viewable and playable in the edit window on the admin size, to make that content all the easier to manage in your post. If your post isn’t necessarily a video post format, you can still embed videos from your media library in the main content area with the use of the [video] short code. Audio content can now also be embedded (or included in audio post formatted posts) with similar ease, using the [audio] short code. Got a video on YouTube you want to embed? That’s even easier: just drop the link in your post where you want the video to appear.

No plugins were harmed in the embedding of this video.

This is functionality that WordPress.com users have enjoyed for a while now, and I, for one, am very excited that this is coming to the self-hosted WordPress world.

Post Locking

This one is sure to make the managers of multi-author blogs very happy: improved post locking. In previous versions of WordPress, the only warning one had when another author was editing the same post as you was a warning in red across the top of the screen. WordPress 3.6 beefs up the post locking notifications, so now you really have to be determined before stepping on someone else’s post.

The first hint is that someone is editing a particular post is in the “All Posts” screen of the admin interface. If someone else is editing a particular post, their gravatar appears next to the post title with the note “[username] is currently editing.” If that’s not enough of a warning for you, and you decided to try and edit the post anyways, a dialog box will then appear:

You now have a choice to back away slowly, see what the other author is up to, or take over editing for yourself (in case the other person went home for the day with the post still in edit mode). Choosing the third option will allow you to edit the post, but block out the other person, a fact he will be aware of when the corresponding warning dialog appears on his screen:

Improved Autosaving

It is the WordPress core team’s stated mission that:

we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc.”
Mark Jaquith

To that end, autosave has been improved, and will now write your autosave information directly to your modern browser’s local storage (where available). So now when you’re on the train and you hit a tunnel, or your Verizon FiOS connection cuts in and out (not like that’s ever happened to me… repeatedly… when trying to meet a client deadline… grrr), you can be assured that whatever you’ve just written is safe and sound on your local machine, ready to sync up again at the next signs of life from the interwebs.

But what happens when you’re working on a post, and you get suddenly called away to work on an emergency? Or your ten minute trip to the sandwich shop turns into an hour and a half long team lunch, and when you get back, all your login cookies have expired? Nothing to worry about there, either. Now if something happens where you lose your session authentication, WordPress will prompt you to re-log in once you resume editing your post. No, not take you to the login screen, but ask you right there, in the post editor screen, for your login credentials. Reenter them as normal, and boom! You’re back right where you left off! Another awesome feature when life gets in the way of your WordPress work.

No session? No problem! Log back in right on your edit post screen.

Revised Revision Management

So what happens when you decide you need to go back in time and retrieve that version of the page you edited three days ago, or three weeks, or three months? The revision management screen has gotten a dose of love now too, with a great slider that lets you easily retrace your steps. Even when you need to compare two historic versions of the posts, the slider will let you scrub to both versions you want to compare.

Scrub your way back in time in the improved revision management screen.

More Intuitive Menu Administration

The customize menus interface was a huge boon for content managers when it first appeared in version 3.0, and now it’s even better. No more having to scroll horizontally through the names of menus along the top of the window; with just three or four long-named menus that got a bit clunky. Instead, you now choose the menu you want to edit by selecting it from a drop-down field. In the left column of the menu management screen, the meta box to select the menu’s location has been removed (it now has its own separate tab at the top of the page), and only collapsable meta boxes related to what can be put in the menus appear.

Menu management is now more intuitive.

It’s a New Theme, Baby

To really showcase the bright new future of post formats, the WordPress core team is releasing it’s annual new default theme, Twenty Thirteen, with the 3.6 release (yes, I know Twenty Twelve came out with 3.5, but that is so last December…). This default theme represents a true departure from the previous default theme efforts. Whereas Twenty Ten, Twenty Eleven and Twenty Twelve could safely be described as monochromatic, Twenty Thirteen is bold! A bright orange banner says to the world “I am no ordinary WordPress default theme!”, and the “bands of color” produced by the variations from different post formats really take advantage of the post format’s new prominence in the WordPress world.

The new default theme, Twenty Thirteen, is a theme of a different color.

Even if the colorful, retro styling is not to your personal taste, the code behind the colors showcases what you can really do with post formats when you put your mind to it. It’s always the hope of the default theme team that theme authors can use it to dissect it and really learn how to take advantage of new WordPress features via the themes they create. I certainly will going forward.

Conclusion

Can’t wait for the released version to try out these new features? You can check out the beta for yourself by heading to http://wordpress.org/news/2013/04/wordpress-3-6-beta-1/. As is always true, beta software is in flux and features are always subject to change before the final release. Use beta software with caution, and never on a production level site.

The WordPress core team is always striving to do one thing: improve the WordPress experience. And with 3.6, I think they’ve hit it out of the park. The new revision management, post locking, autosaving and menus administration will make life much better for content providers and site editors. The new post formats UI and template tags will bring out the creativity of theme developers. And the new default theme, Twenty Thirteen, will certainly have heads turning. Look for the final release to drop in early May.

The post A Preview of WordPress 3.6 appeared first on Treehouse Blog.

Static typing is great because it keeps you out of trouble. Dynamic typing is great because it gets out of your way and lets you get your work done faster. The debate between strongly and dynamically typed languages rages on, but understanding the issue starts with weak typing and languages such as C.

C treats everything like a number. A character like a or 7 or % is the number of the ASCII symbol representing it; “true” and “false” are just 1 and 0.

C defines variables with types such as int for integer and char for character, but that just defines how much memory to use. To access the variable and print it out, I need to know the type.

    int a = 1;
    printf("The number is %i\n", a);
    
    char z = 'z';
    printf("The character is %c\n", z);
    

When I run this program, it shows this:

The number is 1
    The character is z
    

The printf function needs a hint from us to know how to format the variable. If I give the wrong hint…

    char z = 'z';
    printf("The character is %i\n", z);
    

… then I get this:

The character is 122
    

C doesn’t know whether z is a character or an integer; it has a weak type.

Weak typing is fast because there’s no overhead of remembering the different types, but it leads to some nasty bugs. There’s no way to format the z if you don’t know its type ahead of time. Imagine accessing a variable and getting the number 1229799107. The number could be the result of a mathematical calculation (1,229,799,107), the cost of a government program ($1.2 billion) or a date (Saturday, 20 December 2008). When all you have is the number, there’s no way to know that it’s really the code for the letters in my name: zack.

So far, we’ve just covered weak typing. “Weak versus strong” and “static versus dynamic” are often spoken of synonymously, but they each describe a different phase of the same problem. They’re also politicized, with the words carrying an implied value judgment. “Weak versus strong” makes one of them sound a lot better than the other, while “static vs. dynamic” makes one sound stodgy and the other exciting.

(Image: Cris)

These two terms are used interchangeably, but they describe the difference between the way a language defines types and how it figures them out when the program runs. For example:

No programming language fits any of these definitions 100%. Java is considered one of the most static languages, but it implemented a comprehensive reflection API that lets you change classes at runtime, thus resembling more dynamic languages. This feature allows the Java Virtual Machine to support very dynamic languages such as Groovy.

Functional programming languages such as Lisp, Erlang and Haskell blur the lines even more.

Usually when people argue about the merits of strong versus weak programming languages, they really mean the varying degrees of weak, strong, static and dynamic philosophies in every language.

Weak Static Languages: C, C++ And Objective-C

These next programming languages use a subset of C’s functionality and strict guidelines to improve the loose nature of the language. C++ and Objective-C compile into the same bytes as C, but they use the compiler to restrict the code you can write.

In C++ and Objective-C, our number (1229799107) has a meaning. I can define it as a string of characters and make sure that no one uses it as a currency or a date. The compiler enforces its proper use.

Static typing supports objects with sets of functionality that always work in a well-defined way. Now I can create a Person object and make sure the getName function always returns the string of someone’s name.

    class Person {
        public:
            string getName() {
                return "zack";
            }
    };
    

Now I can call my object like this:

    Person p;
    printf("The name is %s\n", p.getName().c_str());
    

Static typing goes a long way to avoid the bugs of weakly typed languages by adding more constraints in the compiler, but it can’t check anything when the program is running because a C++ or Objective-C program is just like C code when it runs. Both languages also leave the option of mixing weakly typed C code with static typed C++ or Objective-C to bypass all of the type checking.

Java goes a step beyond that, adding type checking when the code runs in a virtual machine.

Strong Static Languages: Java

C++ offers some stricter ways of using C; Java makes sure you use them. Java needs everything to be defined so that you know at all times what type of object you have, which functions that object has and whether you’re calling them properly.

Java also stopped supporting C code and other ways of getting out of static typing.

The Person object looks almost the same in Java:

    public class Person {
        public String getName() {
            return "zack";
        }
    }
    

I get the name by creating a new object and calling the getName function, like this:

    public class Main {
        public static void main (String args[]) {
            Person person = new Person();
            System.out.println("The name is " + person.getName());
        }
    }
    

This code creates a new Person object, assigns it to a variable named person, calls the getName function and prints out the value.

If I try to assign my person variable to a different type, such as a character or integer, then the Java compiler will show an error that these types are incompatible. If I was calling a separate API that had changed since I compiled, then the Java runtime would still find the type error.

Java doesn’t allow code outside of a class. It’s a major reason why people complain that Java forces you to write too much boilerplate.

The popularity of Java and its strong adherence to strong typing made a huge impact on the programming landscape. Strong typing advocates lauded Java for fixing the cracks in C++. But many programmers found Java overly prescriptive and rigid. They wanted a fast way to write code without all of the extra definition of Java.

Strong Dynamic Languages: JavaScript, Python, Ruby And Many More

In JavaScript, I define a variable with the keyword var, instead of a type like int or char. I don’t know the type of this variable and I don’t need to until I actually want to access it.

I can define an object in JavaScript with the getName function.

    var person = {
        getName: function() {
            return 'zack';
        }
    };
    
    alert('The name is ' + person.getName());
    

Now I have an object named person, and it has a function named getName. If I call person.getName(), it will result in zack.

I declared person as a var, and I can reassign it to anything.

    var person = {
        getName: function() {
            return 'zack';
        }
    };
    
    person = 5;
    
    alert('The name is ' + person.getName());
    

This code creates a variable named person and assigns it to an object with a getPerson function, but then it reassigns that variable to the number 5. When this code runs, the result is TypeError: Object 5 has no method 'getName'. JavaScript says that the object 5 doesn’t have a function named getName. In Java, this error would come up during compilation, but JavaScript makes you wait for runtime.

I can also change the type of the object based on the conditions of the program.

    var person = {
        getName: function() {
            return 'zack';
        }
    };
    
    if (new Date().getMinutes() > 29) {
        person = 5;
    }
    
    alert('The name is ' + person.getName());
    

Now this code will work at 9:15 but will fail at 9:30. Java would call this a type error, but it’s fine in JavaScript.

The most popular form of dynamic typing is called “duck typing” because the code looks at the object during runtime to determine the type — and if it walks like a duck and quacks like a duck, then it must be a duck.

Duck typing enables you to redefine any object in the middle of the program. It can start as a duck and turn into a swan or goose.

    var person = {
        getName: function() {
            return 'zack';
        }
    };
    
    person['getBirthday'] = function() {
        return 'July 18th';
    };
    
    alert('The name is ' + person.getName() + ' ' + 
          'and the birthday is ' + person.getBirthday());
    

At any point, I can change the nature of my Person object to add the new getBirthday function or to remove existing functionality. Java won’t allow that because you can’t check object types when they’re always changing. Dynamically redefining objects gives you a lot of power, for good and bad.

C shows errors when the program runs. C++, Objective-C and Java use the compiler to catch errors at compile time. JavaScript pushes those errors back to the runtime of the application. That’s why supporters of strong typing hate JavaScript so much: it seems like a big step backward. They’re always looking for JavaScript alternatives.

Which Is Better?

I’m looking for a program to parse XML, find a particular element, make a change and save the file. On a team of Java programmers, I wrote the code in the dynamic language Python.

import sys
    import string
    from xml.dom.minidom import parse
    
    dom = parse(sys.argv[1])
    
    for node in dom.getElementsByTagName('property'):
        attr = node.attributes['name'];
        if attr.value == 'my value':
            node.childNodes[0] = dom.createTextNode('my new value');
    
    file = open(sys.argv[1], 'w');
    file.write(dom.toxml('UTF-8'));
    file.close();
    

This program finds every property node with the name my value and sets the contents to my new value. I define the variables dom for my XML document, node for each node of XML that I find, and attr for the attribute. Python doesn’t even require the keyword var, and it doesn’t know that node has childNodes or that attr has value until I call it.

To change an XML file in Java, I would write a new class, open an input stream, call the DOM parser, traverse the tree, call the right methods on the right elements, and write the file out to an output stream. I could simplify some of those calls with a library, but I’d still have the overhead of defining my static types. All of the extra definition of objects and variables could easily take a hundred lines. Python takes 14.

Dynamic code is generally shorter than static code because it needs less description of what the code is going to do. This program would be shorter in Python than in C++ and shorter in Ruby than in Objective-C.

So, which is better?

Static typing made our Person object easier to understand. We defined a Person with a name and agreed about which fields mattered ahead of time. Establishing everything clearly makes our Person easier to debug but harder to change.

What happens when someone in our application needs a second email address? In a static language, we’d need to redefine the object so that everyone has two email addresses, even though most people don’t. Add in a birthday, favorite color and a few more items and every Person will have twice as many fields as they need.

Dynamic languages make this problem much easier. We can add a second email field to one Person without adding it to everyone. Now, each object has only the fields it needs. A static language could handle this with a generic map of values, but then you’re fighting the static environment to write dynamic code. C programmers spent years tearing their hair out over errors in type conversions, corrupt values, and the terrible bugs that come from small typos. They’ve been burnt by weak typing, and dynamic typing looks weak.

Dynamic programmers spent years banging their heads over the rigidity of static languages, and they crave the freedom to make the languages do what they want.

I’ve seen static code get overly complex and become impossible to follow. Try debugging an enterprise JavaBean or understanding all of the details of generics in Java. I’ve seen dynamic code turn into a giant mound of unmaintainable spaghetti. Look at the myriad of terrible JavaScript programs before jQuery. Node.js does some amazing things, but I can’t look at it without traumatic flashbacks of horrible JavaScript that I’ve debugged.

Conclusion

There’s no clear conclusion. Dynamically typed languages are popular now. The pendulum will swing back and forth many times in the coming years. The only solution is flexibility. Learn to work in each environment and you’ll work well with any team.

Image credits of image on front page: Alexflx54

(al) (ea)

© Zack Grossbart for Smashing Magazine, 2013.

It’s like biting your nails. It’s like sucking your thumb. It’s like cursing too much. We all have some bad habits, some we just cannot seem to shake. I’m not sure why that is. I mean, no matter how wrong you know it is or how bad it is for you, it’s just impossible to stop.

And have you realized that half the time you don’t even notice? Tomorrow, you can look down at your nails and wonder where they’ve disappeared to. And eventually, you’ll remember that you happily nibbled them off.

As a designer, you’re probably no different. You’re a human and no one is perfect, plus design is just a tough industry. Sometimes, we are our own worst enemies with the things we do and we never seem to notice, nor do we stop. Being a designer, there are four things I notice most often that I and my colleagues do:

1. Aesthetics vs. ease of use

We are designers. We are not artists. We are asked to fix problems, create solutions and design things. I could even say, though a stretch, that we are scientists.

Artists typically have less or no rules and make things that make them feel good. But as designers, at the very least, we have to make something that makes our client (and eventually their customer) feel good. We shouldn’t be in the league of creating something pretty. We should be able to do that when necessary, but that shouldn’t be our priority. We must focus on ease of use or making things that make sense.

It’s the reason why we hate fonts like Comic Sans and Papyrus, but love Helvetica. One is readable and serves as a great body font. The others? Well, not so much. Things have to make sense before we make them pretty. It’s why we create sketches and request thorough design briefs before designing a project.

From our navigation menus to our image placement to the bullets we use, it has to be easy to understand. Far too many designers are stuck on an aesthetics first. Projects begin and end with looks rather than how to make things better and easier to understand. And it’s really easy to become concerned with looks when there are so many good designs with a high aesthetic quality. But I’ve learned when you pay attention to creating something with a purpose, aesthetics tend to fall right into place.

2. Looking at trends

We all do it. We look to the new trends list and the infinite number of inspiration posts. And there’s nothing wrong with being up to date, but we have to be really careful with copying and emulating things that are already being done. 

It’s the difference between your web design being regular and being a stand out. We have to use these trends and inspiration as a means to learn how to approach different problems and situations. We’ve got to digest them and regurgitate something new and better.

If we’re serious designers, we have to be forward thinkers who are always looking for the next big thing. How many vintage badges and seals have you seen? How many huge Helvetica or Futura headlines have you seen? Now when are you going to be the person to set the next trends as opposed to following?

3. Only inspired by web design

We just talked about how we love to eat up the new trends that every design is already doing. But something I take great issue with is that we really are only inspired by similar things. We aren’t expanding our inspiration much, unless we’re taking print ideas and putting them on the web. Otherwise, we get inspired for web design by web designs.

Design (and art) tend to make us feel things and allow us to process things differently. By only being inspired by other web design for your web project or other flyer designs for your flyer project, you are cheating yourself out of good things. 

Architecture, photography and even areas like furniture design can open up your eyes to new solutions for 3-column layouts, for example. Checking out some fashion design may give you an idea of what kind of textures and patterns you may want to use for a brand. I’ve even been inspired by a picture frame for a logo design. Anything works.

Also, taking a look into different areas of designs helps to free your mind a bit. It allows you an opportunity to think about your project from a different angle. It enhances your creativity so that you can be more creative with the work you’ve got to do. Taking a look at something different can make all the difference in your designs.

No matter the concentration or area, many designs have faced similar problems you’re trying to solve. Why not attempt to find different approaches and different solutions?

4. Moaning and groaning

I’ve rarely met a designer who hasn’t whined about something. It could be client who’s too cheap or the one who doesn’t understand why it’s taking so long for a “simple” logo. Whichever it is, graphic designers just whine and get upset and never stop. I guess we feel underappreciated and underpaid and just like to have pity parties.

Whatever. I say stop. Right now. Put your foot down with bad clients and remind them of your worth and what you’re doing. When I start a project, I outright let them know the way the relationship works and give them time tables for things. If there’s an issue there, then I immediately know we aren’t a good fit. Also, a trick is to add a couple days or weeks onto your timetable for safety reasons.

No one understands the life of a designer and if you’re really good, chances are you make what you do look real easy. Clients probably don’t have a clue and don’t understand. Clients who are cheap don’t understand the concept of quality nor do the get the difficulty of what you’re doing. If your work, timetables and design process cannot be respected, then save yourself the headache and move right along.

Many don’t understand the worth of designers, and it’s not really their fault. Businesspeople are concerned about their customers and making money and the like. Spending money on something like design may not be what matters to some. And I can guarantee you, that’s not the person you want to work for. Never be afraid to say ‘no’ and never be afraid to respectfully stand up for yourself.

I’m not telling you to overcharge, nor am I telling you to be a snob to your clients, but it’s absolutely necessary that there’s a level of respect in your working relationships. For every cheap client and headache you say no, there’s a good client out there looking for you!

Conclusion

So you can put hot sauce on your thumb or disgusting nail polish on your nails in an attempt to get you to stop, but when you boil it down, you just have to make a conscious decision to make your change. Doing so makes designing much easier and even liberating. There was a point when I decided to make a change it just felt like I wasn’t even working any more. I was just enjoying what I do and making great things. Now it’s your turn. What are you going to stop doing today?

What are some subconscious things you notice you do? Could stopping make you a better designer? Let us know in the comments.

Beginner’s Course: Learn HTML5 & CSS3 Web Design – only $27!