I am just starting a project and the wireframes are ready. But looking at the wireframes it seems that the primary goal was to reduce the number of pages and to include maximum functionality in to a single page.
Taking an example of an organization, the top portion of the page will show the organization details, below that at the left we have an division structure as a tree view, clicking on a division will populate the employee list on the right as a table, and when you click on an employee it will populate the employee details below.
Current wireframe looks something like this:
End user is happy as they can see the entire functionality on a single page and doesn't need to navigate to another page.
But this design reminds me the screen of some old desktop application and I feel that this page is unnecessarily complex- I want to split this in to multiple pages (at least in to three). Also, I am using MVC 4 and splitting this in to multiple pages will definitely help me to reduce the complexities during implementation.
But before arriving at any conclusion and raising any concern, I would like to know what you guys think. Some articles related to User experience are also welcome.
Here's what I think.
Whether the design above is 'right' depends on the target audience and the type of work / business process they need to carry out. There may be a strong business argument for being able to see all the information (org details, divisions, employees and employee details) on one page. It is not unusual to see a lot of information displayed in a page with a lot of interactivity - users expectations have increased because of consumer sites such as Gmail.
The users might find it frustrating if it was broken out into different pages.
To put it another way, I don't think there is a valid technical justification for making the designer change the UI above to split it into different pages.
You would be able to build the UI above in MVC as a single page web application. You will probably need to implement a lot of controller actions to support ajax calls. You're almost certainly going to end up using a lot of JQuery and you are probably also going to end up with a significant amount of JavaScript to write. Also, you'll need to make sure the designer has made good decisions around the sizing of the page. Is it going to be fixed width or dynamic for instance? You'll need to emit well structured HTML in order to achieve that solely using CSS (which I would strongly advise you do).
Related
So I have a highly customized CMS type system where users can manage content on pages. For the most part everything is templatized, however, the home page is unique in so much that it has additional, editable content that a regular page does not have.
The two solutions that I thought of for this are:
1) I could add a new model, controller, and table in the DB making this an entirely new component. However that seems like a lot of trouble to go through for one page.
2) I could add the missing columns for the home page to the general "pages" table, but again that seems sub-optimal as the additional columns would only ever be used for home page.
What's the best way of handling a situation like this? Is there an additional way that I haven't thought of?
IMHO it really depends on the site and how much differs b/n the homepage and other pages as well as what DB-interaction the homepage has. Kind of a tough question to answer generally.
One thing I've done in the past that has worked well is to have a "Home" record in the CMS tool (assuming there's a 'content' field you can access). Then build that custom controller/view for the homepage -- it is the homepage after all.
Add in your custom functionality, custom layout, formatting, etc. And pull that 'content' field from the 'Home' record in the CMS and insert it where relevant.
That way, the CMS staff can still tweak the homepage messaging, but you maintain full db-interactivity over it.
Hope that makes sense.
I wouldn't advise against #2. Seems wasteful.
I ended up just creating a Model, Controller, table, etc. for generic 1-off pages that are flexible as I suspect that I'll have need for additional stand alone pages in the future. The home page is just one of those now with a special route a method in the controller.
I'm working on building a mobile application for a client using jQuery Mobile. The question I have is fairly basic and non-technical:
The application can have three different types of users, all with a different menu layout. Some users will have access to some parts of the system that other users will not.
My question is- should I hardcode the menu system in the index.html file or should I dynamically create it when they log in? I'm assuming that there would be a slight performance gain by hardcoding the menu and then just choosing which #page to display as opposed to requiring an ajax call...but keeping the menu builder on the server side processing keeps us more agile if need to change the menu after deployment.
Deep apologies if this has already been asked. Thanks for your help!
Build your pages dynamically. On jQuery mobile, a lot of stuff will be repeated and if you want to respect the DRY principle and want to create easily maintainable code, do it dynamically.
Also, by doing this on a mobile application you will reduce the loading times : instead of loading 3 pages you'll only load one, wich can be crucial in mobile developpement.
Hard coding is bad if it can be done dynamically do it because it saves over head and produces nicer code that is easier maintainable.
If you want to change the menu in the future you can just edit the source of information instead of going through all your code having tons of messy if and else statements saying if this person is logged in don't show this option but show this one etc.
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
I recently made the decision to develop our new company website (http://www.idealcode.net:8005/AboutUs.aspx) with Umbraco. I hired an Umbraco developer and we started work.
Please don't flame me or anything but I'm starting to worry about my decision.
The main reason why is because I seriously cannot find anything that explains in simple terms the workflow for creating a new page. As a web developer, it seems as much work to create a page in Umbraco than creating one outside of a CMS.
The workflow as we have it is:
Create a master page (probably not required for every page, but in practice seems to be on almost every page)
Create a document type with the PRECISE content areas that will be on the page
I guess at this point our end users can actually create a page...
We spent about 10 hours implementing the blog module and it STILL does not work and the dev needs to customize the template.
As a web developer, I honestly wonder how this is going to save us time? I'm not trying to diss Umbraco--I'm just worried about explaining this to my superiors. I could have created a site with some dynamic areas and blog in ASP.NET MVC in the roughly 20 hours we've spent on this so far...
The best way to get up to speed quickly on Umbraco is to look at the screencasts made from Umbraco corporate:
http://umbraco.tv/products/umbracotv
After that, the Umbraco community is quite good at answering questions and helping out:
http://our.umbraco.org/
As far as your specific question:
I could be wrong, but I think the thing that you aren't leveraging is inheritance. This makes things easier in Umbraco.
First, DocumentTypes can have parents and they inherit the data fields from those parents. For example, a Content Page DocumentType could have the meta information, main content area, and intro text.
Many pages within your site will likely go no further than that. Basically a rich text editor page (think "About Us")
Then when you add the News Item DocumentType, it can inherit all of those fields from Content Page and simply add a Date and Image field (as an example).
DocumentTypes can have many templates available to them. So if the data doesn't change, but the markup (design) does then you can set a new template in the Properties tab.
Templates can have parents as well. So you can build them up like this:
Main Template
|____One Column Layout
|____Generic Content Page
|____News Area
|____Two Column Layout
|____Product Compare
This works just like master pages in ASP.NET.
So this is pretty long winded. Maybe I'll think about a blog post. Does this help at all?
I second your thought, but consider following scenarios:
Umbraco or any CMS is no ideal solution, if:
1) The complete site will end up having only 20 pages
2) There is only a single user / editor of the site
3) The content is not much dynamic and once created will not change over couple of years
4) The site have only maximum 10 end users
5) The data is not pulled from any external source or/and all are static pages
Where as a CMS / Umbraco is solution for:
1) The is dynamic and still growing after first 1000 pages
2) The client have multiple editors and want to maintain history of publications
3) The content is pulled from various external sources
4) Site end users/contributors are 100+ and still growing
5) Last but not least, the site have 1000+++ visitors daily
I can go on and list all the possibilities of having CMS at the first place, but you need to decide and analyse your own requirements. There is no point in deploying a Samurai to kill a mouse, but definitely you should have proper equipment if you are going to hunt a tiger :D, joke apart just don't deploy any CMS for sake of learning.
Mean while, have a look in books available on Umbraco site to get started (http://umbraco.org/get-started/for-developers) or install Runaway module to start with.
Sanjay Zalke
>As a web developer, I honestly wonder how this is going to save us
time
It will save you time once you become proficient. It has a learning curve for sure, but once over that hump it will save you time - (that is not unique to Umbraco). I have used other CMS products that were easier to get my first site up - but then I was disappointed that I pretty much maxed out what the CMS could do for me - so far it doesn't appear that I will outgrow Umbraco's capabilities anytime soon.
Umbraco can be a wise choice if your site content is very dynamic with lots of pages.
The USP of Umbraco is the re-usability of the document types and a clear seperation of mark-up and content. It greatly reduces the headache of the site editor.
Although initially it may seem a bit confusing or i would say intimidating, but with the help of web-casts on http://umbraco.com/help-and-support/video-tutorials and the user forums things can get simpler.
I started using Umbraco a month back and so far experience has been good.
Start thinking about your site in terms of what is in common from one page to another. If every page in your site needs its own master-page than something is wrong. A good site layout will include the flexibility you need from one page to the next, but still enforce consistency and a common design.
Once you have the common elements of all the similar types of pages, start defining document types for this various types of pages. For example, you might have Basic Page document type, a News Item document type. You can define the various other pages, like "HomePage" or "Section Home", etc. If you have a slideshow, you could create a document type for each "slideshow Slide", etc. Umbraco allows you to build out a very flexible content tree very quickly, and is one of its biggest advantages.
Even if I am the only developer on a site, I still prefer using Umbraco over building a non CMS site. Once the site architecture it determined, development becomes very fast.
I have a heavy page that is cached. This is okay for anonymous users. They all see the same page.
The problem is for logged in users. They should have minor parts of the page re-rendered on every request (like personal notes on content in the page, etc.)
But still all the rest of the page should be cached (it does tons of SQL and calcuations when rendered).
As a workaround I put placeholders in page templates (like #var1#, #var2#,..).
Then I make controller method to render View into string, where I do string.Replace #var1# and other into real values.
Any cleaner way to do such kind of partial "non-caching"?
This is called donut caching.
The ASP.Net MVC framework doesn't currently support it, but it's planned for version 3.
To start things off, it might make sense to go through the page and see if there is anything about it that you can do to streamline or reduce the weight. Depending upon how bad things are, investing some time here might pay off in the long run.
That said, in regards to trying to server the content to anonymous as well as logged in users, one option is to have two versions of the page: one for anonymous users and one for logged in users. This may not be the best approach though as it means that you now have two versions of the same page to maintain.
Given the lack of support doughnut caching mentioned by SLaks what I would likely do is try and cache the results of the calculations that are being done for the page (e.g. if you are querying a database for a table of data, cache a DataTable that you can check for before running the operation) and seeing what that does for the performance. It may not be the most elegant solution in the world, but it may solve the problems that you are having.