Thinking at the new TeamMentor 4.0 design from a technical, implementation and shipping point of view, there are 4 kinda-separate parts of the new design.
Expanding on "1) the 4.0 look and feel + basic use (simple navigation, basic search and article viewing)"
This is going to be a website that has as little or no javascript at all.
There are a number of reasons to do this. The first is the current problems that we already have with IE 8 with a couple customers, which is something we need to address (I also want us to be future proof, since over the next couple years a lot more browsers will become 'legacy')
Having used MVC Javascript frameworks like AngularJS, I really don't want us to code in jQuery anymore (since it promotes a kind of 'hack the DOM until it works' development model). Add to that the fact that jQuery is dropping IE 8 support.
Dropping (or minimising) Javascript would also allow us to deal with the cases where TM content/UI needs to be consumed in a 'no script' iframe (like what checkmarx did to us).
Since we are not going to use Javascript to help with user experience, this means that just about all the UI interaction will need to be done at the server side.
But since the pages we are loading are going to be quite small, I don't expect that this will impact a lot the user experience.
For the backend/server-side code, the idea is to use as much of the ASP.NET MVC 5.0 Framework as possible, since that is now a mature technology with lots of powerful web development features (like Controllers, Views, Razor views, JS consolidation, aSync page rendering, etc...)
We could actually use other JS frameworks (like NodeJS), but since a) our current statck is already based on .NET, b) MVC 5.0 has done a lot of catch up and c) our clients are already expecting an IIS based install, I don't think we should change it (there is also a newer OWIN based .NET Stack which is staring to be mature, so there are good things on the horizon from the .NET camp)
1) the 4.0 look and feel + basic use (simple navigation, basic search and article viewing)
2) the 4.0 ' search driven functionality'
3) the 4.0 design with full article (and library / metadata) editing capabilities
4) the 4.0 design on TBot/Admin features
For the 1st one, we should aim to have a full-backwards compatible version of TM. Note that this version would also be the 'TM Mobile' version (i.e. the default way to consume TM on a mobile, or in a small window space like what we get inside an IDE plugin (bootstrap has a 'responsive, mobile first fluid grid system' which makes this easier))
For the 2nd, this is where the main UE and UI thinking/experimentation needs to occur.
The 3rd and 4th is something that I think we should only do after we figure out the 1st and 2nd
That said, it should be possible (once the 1st is done) to apply some of the new design look and feel to the TBot pages (btw, to do TBot properly, we will need to also spend time and effort designing it)
The really big question here is: Which of these components will need to have IE 8 and older browsers support?
I think that if we have the 1st component in a way that it looks good we can say that that version is our default version for IE and Mobile (this can be detected at the backend)
That would leave us the flexibility to use on the other components the powerful javascript frameworks (like AngularJS) that are more are more focused on 'modern browsers' (note that even jQuery is dropping IE 8 support)
Expanding on "1) the 4.0 look and feel + basic use (simple navigation, basic search and article viewing)"
This is going to be a website that has as little or no javascript at all.
There are a number of reasons to do this. The first is the current problems that we already have with IE 8 with a couple customers, which is something we need to address (I also want us to be future proof, since over the next couple years a lot more browsers will become 'legacy')
Having used MVC Javascript frameworks like AngularJS, I really don't want us to code in jQuery anymore (since it promotes a kind of 'hack the DOM until it works' development model). Add to that the fact that jQuery is dropping IE 8 support.
Dropping (or minimising) Javascript would also allow us to deal with the cases where TM content/UI needs to be consumed in a 'no script' iframe (like what checkmarx did to us).
Since we are not going to use Javascript to help with user experience, this means that just about all the UI interaction will need to be done at the server side.
But since the pages we are loading are going to be quite small, I don't expect that this will impact a lot the user experience.
For the backend/server-side code, the idea is to use as much of the ASP.NET MVC 5.0 Framework as possible, since that is now a mature technology with lots of powerful web development features (like Controllers, Views, Razor views, JS consolidation, aSync page rendering, etc...)
We could actually use other JS frameworks (like NodeJS), but since a) our current statck is already based on .NET, b) MVC 5.0 has done a lot of catch up and c) our clients are already expecting an IIS based install, I don't think we should change it (there is also a newer OWIN based .NET Stack which is staring to be mature, so there are good things on the horizon from the .NET camp)
