Saturday, May 15, 2010 12:13 PM
Generally, the attention of the UI designer goes to public sites/applications.
But there are a lot of web based applications that are running inside the firewall. Like intranet sites.
Maybe for small business is it too much to have an intranet, but it becomes important when there many employees and different locations.
An intranet shall be the image of the company and and a reference for the employees. This is by the book.
But in real life Intranet and employees a lot of times are not in the same universe.
Usually it is the repository for all the documents and the applications used for working. But without a strong mapping of the knowledge, it becomes quickly the black-hole of the documents.
Not only.
In fact an intranet is seen as an enforcement from the central company's office.
To be effective, an intranet shall be a meeting point for the employees, where they could find information, news and usable stuff for their daily work.
My uncle, now retired, told me that he felt his company like a family, not like an external "object" which he had an interaction with.
I never forgot this words. I'm used to change job and working environment frequently: I worked a lot of time as freelance and as an employee too, but in any case, this feeling of belonging is something of the past. But not something impossible!
It depends a lot on the approach of the company. And what could be the main vehicle for it? A intranet.
I cannot decide it, but sometimes I can explain the importance of the communication choices to be used on the intranet.
My golden rules are:
- strong information architecture: everyone shall find the documents that he needs
- clear and usable news and information quickly available
- focus on employees interests and needs
- clear brand communication
And this one is NOT the last thing... but the FIRST!
The brand image is what the corporate communicates to the world, but to the employees too. An intranet shall have a clear and consistent branding image: all the information and areas that are inside of the intranet shall be part of it, not many single things each one with their own look&feel.
I've tried to put in this post all that I learned from my experience, but there are a lot of things that we can do to make the daily work of our user better.
Sunday, January 03, 2010 2:02 PM
When I began to write this blog, I decided to write down only posts about something interesting, not only comments and link to other post.
Twitter helps me to do it.
In the last year, my free time to write consistently decreased: I spent at work more time than in my past freelance activity and when I was out, I spent all my time for family, friends and my beautiful mountains.
I presented to some
conference and
camps, talking about
UIX. I like it very much.
But, I miss writing posts. For the new year I'll try to change something in my working life to find the write balance and to spend more time in writing :)
Tuesday, October 20, 2009 1:14 AM
I'm very happy of attending a
UX Camp last Saturday.
Even though I preferred speeches about suggestions and problems then others about UI methodologies, I listened to some very interesting ideas and I met nice people to talk to.
I talked together with
Cristiano about Interfaces for elder users.
A very big part of our society is now excluded from Internet because the interfaces that we are using every day, are too difficult for them. There is more attention on accessibility for people with disabilities, than there is for elder people. But they WANT to understand and use our technological tools, because they know that they are important for them as they are for us.
We have elder people in all our family, so Cristiano and I thought about some ideas for bringing Web Tools to our elder family.
You can find our presentation (it is only in Italian, sorry!) here:
www.slideshare.net/tso_da/senior-20
Thank you all, people there and organizers
Friday, September 18, 2009 7:59 PM
I'm sitting in front of my mac, searching for an idea on how to make a multiple choice usable. I'm in hurry and I've a very short time to do it.
Sadly, but it's every day's story.
I write something on the google seach bar, hoping to find something that can help me.
So, I found Patterns library sites.
Design pattern history
The concept of using a library of examples to find standard solutions to solve common problems was developed by
Christopher Alexander in 1977 in a architectural book.
"The book provides rules and pictures, and leaves decisions to be taken from the precise environment of the project. It describes exact methods for constructing practical, safe, and attractive designs at every scale, from entire regions, through cities, neighborhoods, gardens, buildings, rooms, built-in furniture, and fixtures down to the level of doorknobs."
This concept is widely used in software architecture to organize and to design software, but is a relatively a new concept in UI design.
How patterns could be useful for UI design
In the user interface design using a framework based on "pattern" began with the library of XHTML+CSS modules. Everyone of us knows very well the importance of these libraries and we usually use them to build our code architecture.
The same value has the UI pattern: they immediately give to us an idea of a possible solution to study and solve our personal scenario.Having some elements to begin to work, some answers to basic problems, puts our mind in the condition to think how to improve user experience and consistency related to whole application.
It is not only copy&paste, Patterns give us a different and rational way of approaching a problem, in a context that has very few rational things: design and user experience are not simple to categorize.
There are many examples of UI pattern on the web.
I used three, but I discover every days one new :)
http://quince.infragistics.com/
Is the first UI pattern site that I used. Here it is possible to find some solution organized by type of user tasks.
http://patterntap.com/
This one is a library of samples, not all are real "pattern", but a collection of inspirationl graphic element, organized by kind of problem.
http://www.welie.com/patterns/index.php
This is a collection of pattern for interaction design, that explains what you can use for UI problems and how.
Monday, July 13, 2009 11:57 PM
A few weeks ago I held a talk at the Italian ALT.NET Conference and my talk was about how to design the User Experience of an application, but soon it turned into a hot discussion about how to adopt the approach I was explaining, building the prototype of the UX first, when using an Agile development methodology.
From the objections I received I understood that Agile developers think that UI prototyping is against incremental process, but this is not true.
When it come to prototyping the UX of an application, it doesn't mean you have to prototype the whole application in the finest details. I think that is possible to prototype the concept of an application, with the macro functionalities, the graphics and usability behavior and give the imprinting to the client. Then when the project enters in the development phase, you can use prototyping to design and define the UX in a more detailed way and so develop the single feature in a vertical way.
You can design the functionalitis with the schematics, static graphic and functional mockup and put every single functionality on the client approval process and then implement it. It isn't a closed process, there are a continuous dialog between designers, developers and clients.
Talking with a more precise Agile terminology, you can see the prototypes are a better way to define use cases: a way that shows the customer what he wants, not only from a functional standpoint, but also from a usability one (this is an interesting thought by Simone Chiaretta ). And since this use case is more similar to the final implementation than a bunch of sentences, the customer can understand earlier in the process that what he told you want not what he meant, or that he wants it in a slightly different way. And since this brings earlier in the process something that without prototyping would have been discovered only after the first iteration of the given feature, this save both you and the client time and money.
Obviously, since you are building something concrete (still a kind of sketch, but more concrete than just text) refactoring of the main plan is necessary. Since there are always continuing changes during a project, the process without a global view is too dangerous as it might lead to inconsistencies in the overall design and user experience of the application.
My grandmother says: the truth lies in the middle. Don't think in absolute way, and don't think without a global and elastic mindset. Approaching this you have to adopt the approach that works best with your team: every single project, like every single team, has a particularity that makes it unique.