We have all encountered intranets in our professional lives. Often, the intranet is where information goes to die and is forgotten. How do we break away from this pattern? Depending on whom you ask, some users may view the intranet as a tool to find HR Related information; others may use it to work collaboratively with a team who works remotely, and some will simply resist using it at all.
The road to overcoming common intranet missteps and misconceptions begins with a proper envisioning. We will discuss the process of envisioning a successful intranet, starting with a handful of factors: user and business stakeholder interviews, project requirements, documentation, and being mindful of the unique needs of your users as intranet solutions are not one-size-fits-all between companies—or even between departments within a single company.
The first group of people you are going…
I’m currently working on a solution that exposes a BizTalk Orchestration as a RESTful webservice using WCF-WebHttp. Upon successful processing of the message, the service returns binary data for the client to download. However, if the processing fails, I wanted the service to return application/json data with an error message that would be suitable for consumers – I did not want Stack Traces or other internal details to be provided that could potentially be used by malicious consumers. Further, I wanted to ensure this information was sent in the same session.
Initially, I created a schema with my sanitized error information, set the Fault Operation Message Message Type to that schema, and enabled “Include exception details in faults.” While this did end up including my custom error message, it also included the extra information I was trying to avoid. It also…
I dislike visual clutter. Most people do. Perhaps they can’t articulate it. I know most of our clients say things like, “It looks too crowded,” if presented with something that strikes them that way. They don’t use the words “visual clutter” as we would in design parlance.
However, that idea of clutter-reduction has recently over-reached its bounds in the oft-cited and overused mantra of “flat design.” I’m all for simplifying, but there are some designers who take it too far, slashing and ripping out things that they claim help to simplify the UI to its bare essentials, but they’re only thinking one-dimensionally, pun intended.
When you’re a hands-on CEO, you want to get involved in every aspect of your company. Now, as UX Design becomes a differentiating factor for product and company visibility, CEOs are paying more attention to design, but some, like Yahoo!’s Marissa Mayer, are ham-handing it.
User Experience design has always been, and continues to be, a field riddled with ambiguous labeling and nomenclature. We hear all sorts of conjecture and debate as to what terms have what specific meaning. Are profiles and personas the same thing? When exactly do wireframes become mock-ups? Is “mock-up” supposed to hyphenated? These are issues of semantics, and when it comes to the actual meat of the work we do, we could call a wireframe a “whosamawhatsit” and it wouldn’t change it’s purpose. From the perspective of standardizing our professional space, common labeling is important. This is not in doubt. Client, asset, and project management aside, there is something vital to the decisions that we make as designers that is not addressed as often as it should be: Science.
Creating successful user experiences is an art. A lot of art involves taking advantage of the way that the brain processes information. The most successful designs (user experiences or otherwise) are those that give off feeling of “how else would you do it?”. The design simply seems to make sense. Designing an interface is a more complex process than simply creating links and putting arrows on a page. To compare this process to that of another in art in terms of complexity- let’s have a look at foreshortening. Foreshortening in art is a good illustration of how difficult it is, because it illustrates that something that seems so obvious once it’s done well. It harnesses the power of the brain to fill in the things it’s expecting, even if they aren’t there.
One of the reasons that HTML standards are so important is because HTML is a language that has historically been written with a lot of errors and now has many different versions. One of the rules that has been generally agreed upon by browser makers is “don’t break the web”. This means that all new browser versions have to be able to work with all the older standards and handle errors in code in a meaningful way.
Brief (but required) history lesson:
Back when IE had 90% or so of the market share, browsers were essentially an enigma. It was hard to know exactly how things worked. Now that open source browsers have a significant part of the market share and there is competition between them in terms of functionality, how the browser works is coming into the light.
There are a lot of rules that front end engineers follow and consider standard, but a lot of F2E’s don’t know why we do some things. It’s crucial that you be able to justify to your clients or your boss why you take the time to follow best practices, and to make decisions based on all of the facts.