Taxonomy defines the structure that underpins Knowledge Management, Document Management, Records Management and more. Considerable effort goes into defining & developing taxonomy, with the goal of creating a common structure that will benefit the whole organization. The challenge, however, is to ensure that taxonomy work well for staff, beyond any organizational benefits that are sought. If not designed well, taxonomy can become 'white elephants', too hard to understand and too complex to use. At their worst, poorly designed taxonomy is the direct causes of project and system failure. Information architecture has much to offer those creating taxonomy, including a range of structured techniques for building and testing their effectiveness.
Today I am trying to outline some of the approaches & try to encourage creators of taxonomy to retain a clear focus on usability throughout the design process.
Building taxonomy
Taxonomy is typically drawn from a number of sources, including existing industry-wide classification schemes, business functions and structures already in place within sections of the organization & this is the primary way to do so. Some or all of these are pulled together to create a larger or more complete taxonomy. Testing of this taxonomy usually relies on internal review, discussing the taxonomy with Team & Management, and gaining input on areas of strength and weakness of the proposed Taxonomy. While effective for gaining broad user and stakeholder input, this kind of review is very shallow, and is not sufficient to ensure that the taxonomy can be used in practice. Instead of doing such practice, structured techniques must be used, getting beyond staff and expert opinions to build the Taxonomy.
Following are three clear purposes of a taxonomy:
- knowing where to file information correctly
- retrieving information easily when needed
- meeting legislative, compliance or business objectives
If any of the above mentioned goals are not achieved then it is more likely that taxonomy will fail & normally if We achieve 100% Success on third Point We believe that we have got the final Taxonomy and this will never fail. I have believed many times in my carrier and every time I have proven wrong on my thoughts and when Taxonomy becomes White Elephant it becomes difficult to manage as well as very very difficult to repair the Taxonomy and we have to continue with the same. I would advice you all to consider Information Architecture tools before you finalize any thing on Taxonomy. I am not expert on Information Architecture but still trying to write something on Information Architecture below.
Information Architecture
Information Architecture is a discipline that focuses on creating effective structures and navigation for web sites and intranet Web Applications.
Information Architecture has a toolbox of techniques that can be applied equally well to taxonomy creation. I am trying to do brief outlying on couple of these techniques here (On which I have tried to work on my current project and seems to have got some success), with links to more information. I have been looking for more resources on this and may post some more articles on this area in future. but I have seen in many of my projects that We end the project but never ever Taxonomy gets completed.
Card sorting
A very simple technique for building an understanding of how staff think about information, used as an early input when creating a taxonomy. For more on this technique:
www.boxesandarrows.com/view/card_sorting_a_definitive_guide
Card-based classification evaluation
Provides a rapid way of testing a taxonomy to ensure that staff can correctly store information and find it again later. For more Details on this technique:
www.boxesandarrows.com/view/card_based_classification_evaluation
Usability testing
Designed to test the overall ease of use and effectiveness of not just the taxonomy, but the system used to implement it. Should be used throughout the design and implementation process.
Best-practice approaches
It is no longer sufficient to simply gather staff input to assess the effectiveness of taxonomies. Instead, practical Information Architecture should be used to ensure that a taxonomy works in practice. Also Information Architecture practice can change on project to project basis.
I've heard some developers arguing that SharePoint is a threat to their job security because it allows end-users to do things that previously only they had the "power" to do. Look at how easy it is to provision new sites from a top-level site. WSS handles all of the underlying IIS interaction for you. And when you look at what users can do with the BDC (Business Data Catalog), I can understand why many developers shudder.
Being working as SharePoint Architect as well as .net Architect I never felt so on the contrary I always felt that SharePoint is great tool for developers. New Development opportunities opened by SharePoint is mostly not viewed by most of the Developers. I would say that .net is Development framework and SharePoint is great Platform to Build Enterprise Applications for .net Developer's. SharePoint has various flavors of its own and one need to find which flavor suits him it has some opportunities for Designers to work with SharePoint Designers and have great capabilities for Seasoned .net Developers with .net 2.0 & .net 3.0 SharePoint very well uses windows workflow foundation and supports hosting of complex web forms created using info path. It has its own SDK for Hardcore Developers to really work on SharePoint and add value to enterprise.
My message to developers who feel threatened by MOSS is…use it to your advantage. Let it handle the tedious pieces of your application (managing search Crawling, Creating List's & Managing Events and many other things which are nothing but huge time consuming Development efforts). Get more focused on delivering capabilities that will help drive business, and leverage MOSS's infrastructure as an entry-point into your targeted clientele.
In my future post I shall post couple of more posts on SharePoint & .net Development I would rather say Office 2007 Suite and development and then will talk about .net 3.5 and various features of .net 3.5
I have recently started Blogging so I may be doing some big mistakes so if you guys can suggest me then it will be great for me to improve my future posts...............
This is my first Post on a new Blog account for me on asp.net and First thing I would like to let viewers know about my brief profile. I have a small IT Carrier for about 8 years and During this 8 Years I have been to various roles around Technologies.
I Started my Carrier as C++ Developer and initially turned towards Java during my initial years of carrier till Year 2002 I was Playing between Java, C++, Classic ASP & PHP Development. During Year 2002 I turned to be working on .net 1.0 with VB.net and I was mainly involved with ASP.net Development by the Launch of .net 1.1 become Sr. .net Developer and was also given responsibility to assist technical Architect to the Project and by that time I started working on C# mainly. Worked on .net 1.1 and moved to 2.0 and During Year 2006 I become Technical Architect to the Project and was working on .net 2.0 based solutions During Late 2006 I was having a project where SharePoint was required to be the main tool for the Project and I finished my first Project as .net Architect as well as SharePoint Architect. Currently I am working as Solutions Architect on Microsoft Technology and working on one of the major SharePoint Implementation Project.
I was having feeling that there is nothing for Developers with SharePoint but the more I work on SharePoint I get more and more Idea's on what can be done using .net to make SharePoint Better for my customers. Will try to Blog more and more on Development Opportunity with SharePoint and some of my other experience with ASP.net Developement and .net 3.5 based solutions which I am working on.