Mobile devices are rapidly becoming the go-to choice for internet access for consumers.  Reading takes place on a wide range of devices, from a small smartphone to a large computer monitor. A design that works well on one screen size may not be readable on another. The user’s experience with your mobile app is paramount, and should be the outcome of significant thought, design, investment, testing, and refinement. It’s easy to discuss the need for an interface to be simple, usable, and concise. It’s surprisingly difficult to create an interface that fulfills those needs.

As designers, developers, and UX practitioners who strive to achieve business success through designing mobile experiences, we face many design challenges.

  • What is the right interface solution for my project (responsive design, adaptive design, native app, etc.)?
  • How do I choose the right navigation?
  • What is the right layout approach for maximizing the use of the screen real estate?
  • When and how should I use the various patterns/ screen elements available across mobile operating systems?
  • What are the interaction and visual design considerations across device types?
  • What are the best methods for prototyping and usability testing a mobile project?

Creating mobile user experiences that engages user’s forces us to rethink a lot of what we have taken for granted so far with desktop design. It is complicated in part by mobile-specific considerations that go hand in hand with small screens, wide variations in device features, constraints in usage and connectivity, and the hard-to-identify-but-ever-changing mobile context. Read More…

Intranet 101: If your employees still use email to request information that’s on your intranet, your intranet is failing.

Maybe it’s too hard to update, so everyone simply assumes the information there is outdated. Maybe the search functionality consistently returns irrelevant results. Maybe it’s not accessible from a smartphone or tablet.

Whatever the reason, the result is the same: poor user adoption has doomed your intranet.

For over 30 years, we’ve been building complex intranets for businesses and organizations of all types and sizes, leveraging the latest technology platforms to create beautiful, usable intranets that solve business problems and eliminate common user pain points.

Our latest whitepaper, Building the Intranet Your Employees Expect, walks you through the building blocks required to design an intranet that not only incorporates today’s capabilities and features, but will also be an essential system that gets adopted, used and loved by your employees. Download your copy today!

In the world of SharePoint upgrades and migrations, a number of terms are thrown around and often used interchangeably. This post outlines several key terms that will be surfaced throughout a three-part series on upgrade/migration strategies for SharePoint 2013. If you would like to jump to another post, use the links below:

  • Part 1 – Definitions (this post)
  • Part 2 – Considerations Outside of SharePoint (Coming soon)
  • Part 3 – Diving into Database Attach (Coming soon)

In past revisions of SharePoint, we had multiple ways to upgrade our farms (and the content within them) to the latest version using the tooling Microsoft provides. Over the years, Microsoft used a number of terms related to the types of upgrade available:

  • In-place upgrade – Often considered the easiest approach, but the most risky. The setup of the new system is performed on existing hardware and servers.
  • Gradual upgrade – Allows for a side-by-side installation of the old and new versions of SharePoint.
  • Database attach/migration – Allows for the installation and configuration of an entirely new environment where content is first migrated, and then upgraded to the desired state.

As SharePoint matured, the number of available upgrade options dwindled. For instance, in an upgrade from SharePoint Portal Server 2003 to Office SharePoint Server 2007, we could follow any one of the three upgrade paths noted above to reach our desired end state. In an upgrade of Office SharePoint Server 2007 to SharePoint Server 2010 we still had two paths available: the in-place upgrade and the database attach approach. For SharePoint 2013, we’re left with just the database attach approach.

Before we dive further into the database attach upgrade scenario, it’s helpful to take a step back and establish a common language as we discuss the upgrade process. Read More…

Welcome to part three of a blog series based on my latest PluralSight course: Applied Windows Azure. Previously, we’ve discussed Azure Web Sites and Azure Worker Roles.

Motivation

Windows Azure Active Directory (WAAD) is another important building block offered as part of the Windows Azure platform. You can think of WAAD as a repository for your organization’s directory data in the cloud. Directory objects include users and groups along with their identity and access information.

By externalizing the directory data into a common location (WAAD), it is possible to provide a single sign-on and sign-out experience for enterprise applications, as well as SaaS offerings.

While WAAD is a cloud-based service, you can use it for on-premises in addition to cloud-based applications. Read More…

Welcome to part two of a blog series based on my latest PluralSight course: Applied Windows Azure. If you missed part one, you can read it here.

Motivation

Azure Worker Roles are executing units that can be used to offload long-running, compute-intensive tasks. You can also think of them as “managed” VMs that execute custom tasks for you. I refer to VMs as “managed” because you don’t have to worry about OS, patches, fault-tolerant setup, etc. Worker roles are backed by a 99.95 uptime SLA. Furthermore, it is possible to dynamically scale worker roles based on load (both horizontally by adding more worker role instances, and vertically by provisioning larger VMs). Read More…