Hello,
We’re building a state service portal that gives a set of permission documents by a request. I’d like you to suggest better information architecture based on SharePoint lists, columns and content types.
There are 30 types of requests from child adoption to building a house. Every request can be sent by either a person or an organization. So every request should contain a block of fields about the author (person or/and organization). However, depending on the type, a request also contains a unique block of fields that describes the object of the request (f.e. a construction site address, or some info about a child to adopt, or some params of a building to construct). The requests then are counted different in statistics reports, like how many were approved, denied or being in work and so on. The requests are also grouped by their statuses and categories (like “my requests”, “requests assigned to me”
So now I’m thinking about how to organize the architecture of this information in a better way. Do you have any ideas?
Wow, nothing like a bit of SharePoint complexity to set the heart racing! Some good thinking in those solutions.
The key point that I can see is that variant 2 has one main list (with the 30 content types). This would be easier to control, create views and report on. Content types being specific for each request are easier to update and change if required. I have used content types for different forms, in terms of containing all the required fields (in this case your request form) and it works well especially for creating web forms and workflows.
You might have to build a mini version for testing without creating all the content types.
Hope that helps Michael.
Hello, Andrew. Thanks for your quick reply. First of all about the users’ needs, they need a form constructor which is based on cutom meta data and after the forms for requests are constructed another group of users will fill in the forms and monitor all the workflows.
So I do have such a constructor but my problem is how better organize my datat storage. So far I have two variants and i’d like yo discuss shich one would better suit my needs. But before I’d like to describe the structure of a request. We have 30 types of requests. Each request type consists of several group of fields (in order to group fields in the web form, but not only). Let’s suppose we have 3 block of fields — A, B, and C. Then requests could look like this:
Request type 1 contains two blocks: A and BÂ Â
Request type 2 contains two blocks: A and C
Request type 3 contains two blocks: A, B and C
etc.
For example:
Request type 1
— Group A (Personal Data)
—- LastName
—- FirstName
— Group B (Resident Address)
—- Country
—- City
—- Street
—- Office
Request type 2
— Group A Personal Data
—- LastName
—- FirstName
— Group C (Work Place)
—- Company Name
—- Company City
So now about two variants.
Variant A:
I will create sharepoint content type on each group of fields.
Then I create a list “Request” that will contain common info for every request (f.e. ID and the Author).
Then I create a list “Request Data” that will contain items of all the content types associated with a particular request.
All the items are conntected by the same “Request ID” value via a lookup fields referenced to the “All Requests” list.
Variant B:
I create a content type for each request type (30 all together)
Then I create one list of requests — that wil be contan items of all 30 content types.
I attached two screen shots to show UML models of my two varians .
Variant 2
Variant B
Thanks.
Hi Michael
You have look first at defining the users of the site and what information they need to see, what tasks they have to do and what outcomes you need to show from a reporting point of view. You have already done this to a point but need to see it from the users end.
So look at it from the users point of view. Where do they start? What options do they have when they get on a page? What do you want them to do? The purpose of IA is to guide people along a path. Determine what the paths are for the content you are creating then see how you can present that information.
You could create pages or sections or dashboards depending on the users, use links/button images to create new forms from content types and then create all the necessary views in the relevant lists.
One option for keeping all the data on a dashboard page is this Tabs solution which is a great way of bring multiple lists/documents onto a single page. This works great and is simple to set up (no code required!). It’s also great for end users as they don’t have to click around to different pages, lists or views. You keep them on a single page.
Â
http://www.bitsofsharepoint.com/ExamplePoint/Site/TabPage.aspx
Hope that helps.
regards
Andrew
