A mobile site is required; it is not a nice-to-have. Mobile Internet usage will be more frequent than desktop Internet usage in the near future, so it’s time to stop adapting desktop websites to fit on mobile devices. We’ve seen the rise of responsive layouts, and while they offer an elegant solution for resizing components for varying screen size, they do little to address the true differences between mobile and desktop usage. Both types of sites need to be designed, but from now on we start with mobile.

Mobile devices offer a number of constraints that do not exist on a desktop. They have smaller screens, and slower, less reliable connections (for now). Inputs are touch and gesture based. Mobile users access the Internet more often than desktop users. They might be waiting for a restaurant table, watching television, or even multi-tasking with their laptop. They often have less attention available than a desktop user. Most importantly, there is a growing number of users who access the internet almost exclusively via a mobile device. Design for these constraints first, and a desktop version will follow much more easily than constraining a desktop version for mobile.

By designing for mobile usage, we force ourselves to be succinct and simple. These constraints will not make our stakeholders happy, but abiding by them allows us to understand the priorities and hierarchy of the site much faster. Stakeholders are more willing to trim the unnecessary and compress their content when crafting a mobile site. Secondary content can be placed on separate screens, making the primary focus of each screen much clearer. When combined with clear and concise content, our users will understand what we want to show them in record time.

If our users can accomplish their tasks on a mobile site, our desktop site will be even better. We now have content that is quick and obvious, an interaction flow that takes little time and attention, and an obvious hierarchy of elements on each screen. Our site is lightweight enough for slow connections, and optimized for distracted users with short attention spans. We have clear calls to action, and large, easy-to-target controls. In theory, both usability and conversions should be better than ever.

While our mobile-optimized site works pretty well on a desktop, we need to take advantage of the platform. While fonts and controls will likely appear friendlier and easier to use, they will be so enormous as to require our users to move their cursors much farther when navigating our site. We also aren’t taking advantage of the extra real estate, screen resolution, computing power, more reliable connection, and precision and hover abilities of the mouse cursor.

When we repurpose our site for desktop usage, we can expand on any content that required trimming, but if our site already converts so well, adding more content will only be a distraction. The main things to do when repurposing a mobile-optimized site for desktop use is to ensure gesture-based interactions are replaced with mouse-friendly alternatives, and to add a little wow factor through the use of animations, transitions, hover states, and higher resolution images which are too much for a mobile site. We may also want to flatten some of the architecture to bring secondary content into sidebars, and provide a larger view of navigation. Just ensure that they don’t interfere with the primary tasks the users want to accomplish.

Personal Capital recently updated its iPhone/iPad application to include a new 401k fund fee feature as well as add support for iOS 6 and iPhone 5. Adding support for a new OS as well as a new device, especially one with a new screen size, is always a great test to a project’s architecture and code. A properly architected project allows the developer to add support for new features with minimal adjustments to the project.

The Personal Capital iPhone/iPad project is a testament to the value of not using WYSIWYG tools. The application supports a range of operating systems as far back as 4.3, and takes advantage of each device’s retina display if available. Every screen is created purely from code and takes advantage of Apple’s APIs that allow a view to re-size and/or adjust the position and functionality of objects based on the current screen size and device rotation. Based on this architecture, updating the project to support iOS 6 and iPhone 5’s 4-inch display only required a few changes.

WYSIWYG tools are SDK dependent. This means that when a new feature is introduced, there will need to be an update to the SDK and accompanying WYSIWYG tool to support these features. Since these features did not exist in the previous WYSIWYG, you will need to update each of the corresponding WYSIWYG files associated with the tool to correctly utilize these features.  For example, the latest version of XCode’s Interface Builder allows support for the iPhone 5’s new 4-inch retina display by providing an additional “Size” property for views.   If your application uses Interface Builder to create its screens, you will need to update each of your nib files if you want your application’s views to re-size correctly.  If your project was built without Interface Builder and is coded for a dynamic screen size by utilizing the frame and bound properties of a view, you don’t need to do anything to your code to support additional screen sizes and layouts.

When a new OS rolls out, there are exciting new features to take advantage of as well as deprecated methods.  If your project is fully code-based, you can do a simple word search to find the points in your code that you want to update.  WYSIWYG tools are unique to each SDK but most are not easily searchable since they are designed to be visual tools.  If the WYSIWYG files aren’t binary, you can do a word search on them but most likely the keywords you need to search upon are specific to the tool and will be different than the property or method name associated with the class’s code-based counterpart.  This means even if you can search upon a WYSIWYG file, your efforts are doubled.

This brings me to the concept of developing for multiple clients.  Successful applications will eventually port to multiple clients and the need to not have to “reinvent the wheel” for each client is essential.  If you are building an application that doesn’t need to utilize UI elements specific to a platform, you can develop your entire application in C so it compiles for iPhone/iPad devices and also support Android devices using the Android NDK.  Obviously, this approach is great for code-reuse but doesn’t allow you to utilize some platform specific features that are accessed via platform specific classes.  I’d love to build an application completely in C so that the code is shared across platforms, but this way can be a little masochistic if you actually want to incorporate platform specific elements into your application.

So what options are left?  If the exact code can’t be reused across clients, you can still reuse the logic.  The Personal Capital application features a variety of dynamic and interactive visual elements that are all built using custom code.  Since they are built entirely in Objective-C without the use of a WYSIWYG, I was able to take the exact code and “Javacize” it for the Android platform.  This meant literally taking the code and just changing it to Java but leaving the logic.  I had not looked at parts of the code in months, so some of it was a little foreign to me.  Since I was simply converting Objective-C to Java, though, it didn’t matter.  This means sections of an application that had been complicated to create on one platform can be delegated to anyone who knows both Objective-C and Java even if they aren’t familiar with the code.

Reusing code in this manner also facilitates the QA process of application development.  Since the same logic is used on all platforms, your QA department doesn’t have to deal with testing a completely new product.  Any issues that arise can be fixed by resolving the issue on one client and then quickly mapped to the other clients.

If portions of your application are created with platform specific WYSIWYG tools, though, this process begins to fall apart.  Besides being platform specific, WYSIWYG tools create a black-box effect on a project.  Most tools do not go into depth the one-to-one relationship between what is being achieved and how to accomplish it in code.  If a developer is familiar with the platform API and its classes, the process becomes mappable, but at this level of understanding, most developers opt out of using a WYSIWYG for actual code since it’s more dynamic and customizable.

There are cross-platform WYSIWYG tools, most of which are HTML5 based.  Many of the simpler applications that you see in the market place actually could have been built using these tools which would have saved the developer the hassle of managing multiple code-bases.  But the key word is simple.  HTML5 applications will never perform as well as a native application and can’t integrate platform specific functionality at the level that a native application can.

There is nothing wrong with using a WYSIWYG if you’re new to a development environment and need to get up and running quickly.  But if your developing complex, dynamic applications that extend beyond out-of-the-box platform elements, you will find that most of your work will be done in code and you’ll most likely drop the use of any WYSIWYG implementation to maintain a clean code-base that can be ported to different platforms.