There’s a lot of work still to be done, but we’ve built the foundation for themes in WPtouch 2.0. And the great thing about it is that you can toggle between them on the fly easily, without any FTP finagling.

There will be a few official themes to choose from when we launch, all of which will take advantage of the same settings and features of the original theme. But you don’t have to rely on just our theme releases, because we’ve built support for the ability to create your own custom themes and select them as well.

Developers?

So of course, if you’ve already modified WPtouch to your own liking, we want to hear about it. Get in touch with us and if we like what you’ve done, we’ll set you up to convert your theme to be WPtouch 2.0 compatible. In exchange for your hard work we’ll provide you with a free copy of WPtouch 2.0 when it’s released with free upgrades for life as well.

It’s really simple to create your own theme: copy the default folder to the /custom folder in the wptouch directory, and start editing! We commented lots in the template files to help guide you as to what’s editable and what’s not if you want to maintain the customization features and admin options. When you’re done, simply change the information inside the theme_info.txt file (theme description, author, URL) and it’ll be reflected in the WPtouch admin as a custom theme now selectable.

As we move along we’ll host the custom themes on the site for people to browse and download.

Don’t Overwrite Me!

We’ve also changed things around so that your custom themes and icons won’t get overwritten when you upgrade WPtouch. WPtouch will only overwrite itself and the official themes and icons, leaving your changes intact.

We’ll release more details and some screenshots & screencasts in the weeks ahead, so stay tuned.

Style Is Everything

While we recognize that many of you are content with the original “iPhone-application-like” design that WPtouch employs, we also recognize the opportunity to foster some really unique implementations by supporting and encouraging themes. We look forward to seeing what everyone can come up with!

Ever seen this Steve Jobs video? That’s how we feel right now, Boom!

We’ve added an often-requested feature, kinda.

Some have complained that the search & menu drop downs don’t work, along with the post-excerpt drop down functions, ajax, etc. Those effects are all done using Prototype-based javascript. On some installations, users may have other plugins which are loading similar scripts, and because WPtouch doesn’t interfere with the loading of those plugins, the scripts get loaded with WPtouch and effectively disable its effects and advanced features.

So we decided the best way around that was to create a fucntion which would change the way that javascript effects work with WPtouch, and bypass the loading of Prototype altogether. This has multiple advantages (more…)

As most people know, both WordPress and Drupal belong to the class of software known as content management systems (CMS). The benefit of these systems is that they allow users to create content easily, often by typing in content via a dashboard or some other simple form of entry. The actual HTML generation is taken care of by the CMS, allowing the user to focus on creating content without worrying about the details of the HTML.

I’ve had my personal blog for nearly ten years now, and have been on WordPress for nearly three. As I write content, there’s always the implicit expectation that my content will come with me wherever I go in the future, no matter which CMS platform I end up choosing. With that in mind, it’s important for that content to translate properly as technology and our use of that technology changes (for example, screen resolutions increase, or the world shifts slowly towards mobile blogging).

When an image is inserted in a post, many people still hardcode the width and height parameters of the image. The problem with that approach is that it generally ties the content to a particular presentation, and makes it difficult to transition in the future. For example, let’s say you manually specify a width of 400px for an image. If one day you decide to change your theme post area to display 500px worth of content, suddenly all your images are too small. To fix the problem, you most likely have to go through and manually edit every IMG HTML tags to change the width. On a blog with 1000 entries, that doesn’t sound particularly exciting, does it?

A far better approach is to use CSS to specify the desired width and height. Most modern browsers support the “max-width” parameter, and those that don’t typically have workarounds. With that approach, you can simply change the layout via CSS whenever you want to overhaul the look and feel of all your images.

For some people, that probably sounds really straightforward. And yet, many third party plugins (and in fact, some popular CMS systems), add hardcoded width and height parameters to content. Every use video from YouTube or other services? If so, you’ll also probably notice that the EMBED code contains specific width and height parameters, which for most people don’t work well with their blog’s theme. What happens when you view a 500px video on a 320px screen? You could be in trouble if the width is hardcoded.

We fixed some of these problems with Blip.it, and made the plugin automatically generate it’s own width and height. We’ve also been testing out a new BraveNewCode video plugin on my personal blog that addresses this problem in a more generic way. Using WordPress 2.5 and above, you can simply use a shortcode to access any video on the web, and have it automatically size to the proper dimensions on your blog. Should you adjust your theme presentation sometime in the future, you can simply adjust the width and height for all videos in the dashboard, and have all your previous content automatically change as well. In addition, the code generated by the plugin validates against W3C in all cases, unlike the EMBED tag (that YouTube and others still provide) which was deprecated.

Anytime you generate content that has an explicit width or height tied to it, you really need to stop and think if there’s an alternative. You may very well be affecting the future look and feel of your website by doing so.

Working with the team at theurbanproject.org recently was a pleasure- we at BraveNewCode had the opportunity to do a flash to WordPress conversion which gave administrative control over the website a decisive boost, enabling the fast and easy editing of pages, posts, and site content from anywhere in the world through a web browser.

The possibilities for WordPress as a bonafide CMS are always growing, and plugins like WPLite only enhance that possibility. With WPLite you can remove unnecessary aspects of the WordPress back-end from the eyes of your clients, helping them focus on and learn the pertinent aspects of the WordPress publishing platform easily and effectively. The WPLite admin page let’s you select/deselect checkboxes for almost every single WordPress feature/page/option.

For first-time WordPress client users, this plugin will become essential to ensuring they feel comfortable with diving in and managing content for themselves.

The work itself was rather standard, but the highlight for me was being able to convert the site from its flash roots to WordPress in only a few days, including full cross-browser compatibility testing and the addition of a few new site features. It goes to show that we’ve got our work process down, and can come through for clients with limited timelines and deliver the intended content.

We’re proud to have been involved with the team at Urban Project, and wholeheartedly wish to extend our best to them in their efforts going forward.

One of the more notable critiques of WPtouch (well not just WPtouch, but any website formatted for the iPhone/iPod touch) is that mobileSafari does a great job of showing websites the way they are regularly, so why bother tailoring sites for the devices?

There were a number of considerations we grappled with when creating WPtouch, and this was of course one of them. The whole impetus for WPtouch was based upon our usage of iPhones and iPod touches, and the sense that in some cases, something like what we’ve created would be more appealing/desireable for visitors than visiting some websites as they are now. It was not just a concept which we thought cool- it was an approach to WordPress on the iPhone and iPod touch which we thought would not just help with viewing on the devices but actually enhance it.

So let me rifle off a few things we thought about while developing WPtouch. In short, there were three considerations we looked at which gave rise to the need for something like WPtouch: speed/size of webpages & load times, accessibly on a touch-based interface, and providing the visitor with the option to choose how they’d like to view the site.

JS Molasses

Firstly, if a website regularly employs oodles of javascript then it will likely load slow on the iPhone. The meager processor on the iPhone/iPod touch can’t get through the JS as fast as if the site was aware of the device’s limitations and served up a more digestible version. This is especially noticable over EDGE connections.

Zoom And Gloom

Secondly, all the zooming in/out isn’t for everyone, and getting to the content you want isn’t as friendly as it is wowing.

All The Same Features, Half The Fat!

Thirdly, you can format a blog (like we have with WPtouch) in a unique way that tailors the site for this specific device (touch interface) without being tacky and without taking away any of a blog’s features (pages, comments, search, categories, tags etc). The iPhone/touch is plenty capable of handling some javascript, but using it smartly, tastefully, and appropriately will yield a much better browsing experience.

One of the drawbacks of using a plugin like ContentRobot’s iWphone, is that you can’t switch between the custom mobile view and the site’s regular view. We’ve developed WPtouch such that visitors can choose between the WPtouch view and a site’s regular view, providing the end user with a choice.

As website designers/developers, we often run into situations where the capabilities of one browser differ from another’s, as each major browser freely available today (Internet Explorer, Firefox, Opera, Safari) offers both support for commonly accepted web standards (for the most part) and also has proprietary features which enable advanced functions. For some web projects, the employment of different CSS declarations is necessary to bring about the most similar user experience across browsers and platforms. In other cases enhancements upon proprietary features are available to users of a particular browser and not others (as is the case with matthewgood.org).

In the case of WPtouch, we wanted it to perform like an enhancement on a WordPress-based website which visitors had the option to use or not, and was specifically designed for mobile Safari. This way it’s not a forced decision on the part of the website host to re-format content in the WPtouch way, but rather offer it as an option to the end-user visiting on one of Apple’s popular devices.

For some websites, using WPtouch makes no sense or is not necessary- for others, it’s the perfect compliment and actually adds something to the website/blog. As with any WordPress plugin, it all depends on the needs of the owner whether or not a particular plugins’ functionality is needed.

WPtouch is no slight on mobileSafari, either… in fact it’s quite the contrary: without mobileSafari’s rich features, WPtouch wouldn’t be possible. Ironically it is mobileSafari’s capabilities that provide for WPtouch, not the opposite.