Web app design / philosophy

Hi,

Sorry, this has turned into quite an epic post :slight_smile:

It’s more of an application design question… I hope this is still an appropriate place for it - I think it will attract more opinions here than in the theory forums.

We’re facing some interesting challenges at work currently and I just wanted to throw around a few ideas and get some feedback on them.
Our apps are built with Microsoft technologies - ASP, .NET C#, SQL, IIS etc…

You can think of our products to be separated by these user groups:

  • Administrators
  • Employees
  • Public users

The admin system is Really Large, maybe 70% asp, 30% .net.
The employee system is new and relatively small <100 pages - 100% .net.
The public systems are 90% asp and have the most legacy code.

Future work will be done on all these systems, yet in different ways:

  • Admin - Mainly maintenance and small upgrades, performance enhancements, extended language support for global access, some new development.
  • Employees - Large amounts of new development.
  • public systems - Maintenance, small upgrades, scalability, not as much new development.

We are finding that there is cross over between development that has been done in the one system and functionality that is needed in the other systems - so the plan is to combine thes codebases so we can share code more completely and also to enforce the thinking amongst developers of them all as one system.

Currently the systems look completely different, though they share obvious similarities like forms, tables, certain controls. etc…

I don’t want to be too critical of the great work that has been done - however I think we have a very poor design process that allows anyone to introduce badly designed code and have it multiplied before it is proven / tested / criticised (lovingly).

I see we have a unique opportunity with our new Employee system to correct the way we approach design. Because it is still small and separate – we can make any change we want there to the framework / design without worrying about the other systems. I think this has huge benefits in the design stage because we can change anything or everything.

It seems to me, with the everyday development that takes place design simply doesn’t happen – we build our small little piece irrespective of the larger picture of the applications.
We’ve introduce the Agile methodology so we have much more direct interaction with the clients – now, Agile has introduced huge benefits – however, the clients are now directly designing the products in a way that didn’t happen previously.

Design is #flipping-important to me, more so than any other part of my work. I just can’t help but see the benefits of good design. I find absolutely no pleasure in fixing bugs that are a result of bad design decisions. No satisfaction, what so ever, in going through 100 pages and fixing something that should never have been in the first place.

I have an idea that I hope and pray will solve all my woes in one fell swoop. Standardisation.

Before you gawk, hear me out.
Our company has some very talented individuals in all areas of application design and business - I believe that anyone passionate and proven in their respective disciplines should be able to work together to form a good standardised framework of how we want our products to look, behave and be built.

I believe that before we multiply the use of some piece of code it should have passed certain tests and be made into a standard we can then replicate.

Now, we do have certain quality checks in place – manual, automated tests, code reviews. It’s simply not working in the way I would like it to though – We are constantly chasing our tails to improve the design when problems are recognised and their priority is increased. In a sense we are very reactive to design problems – not proactive in ensuring good design.

I have a few thoughts that I would like you to sanity check if you could:

  1. Get everyone using the new products – and Loving them. [*]Convince business that design is important – time / money saving.
  2. Create ‘some place’ separate where we can experiment with different designs (technical, functional, aesthetic).
  3. User testing, feedback on this separate code-base from all interested
  4. Filter feedback, improve design, re-release
  5. Formalise a particular design as a standard
  6. Make standardised ‘component’ accessible to all the products for re-use

We will have designed these components so that we can evolve the design of each separately, and in one place.

I suspect this will cause some heated debate, mainly because things will take longer to develop initially, individuals won’t have as much power – it will need to pass the standards of the team members.

Philosophy is hard work. Changing the way people think is tiring when something you are passionate about is not highly valued by your team. The things that are obvious to me are not obvious to everyone so I need to work extra hard at explaining those things that have made their way into my continued thinking.
Whilst my company highly values it’s employees - I find it particularly difficult to share my beliefs about areas I think need improvement. I suspect for a few reasons:

  • I’m the lone-ranging front-end developer on a floor of around 30 Developers, BA’s and Testers.
  • The company was highly successful without my input (before I started) - though there was a previous front-end guy who did a lot of great work on standardisation.
  • I’m opinionated :slight_smile: - I strongly believe in Design, Usability, Accessibility, Web Standards and this in a way makes me very disagreeable at times.

Not sure of my question exactly – any feedback on anything above is appreciated.

  • Is one system a good decision?
  • Do you believe standardisation like I am describing would work / and be beneficial?
  • What is the simplest way to share a belief in something?

Work is fun and challenging – however it’s becoming more tiring as my responsibilities are increasing and I’m being made to defend my position continually - I would have chosen a career in politics or law if I wanted to argue or speak over another :slight_smile:

Thanks,

There are many existing frameworks which are available. So would it be difficult to adapt your code to one of those, instead of creating your own framework ?

It’s a good question. In short - YES it would be very difficult to use a completely different framework. Over the last 12 years or so we have developed some really great pieces of a framework.

It’s also difficult to define what our ‘framework’ is - It’s .net so that’s the framework in a sense. We have created our own parts of the ‘complete framework’ at certain layers of the application though.

It’s also a very mature and large system that is used and relied on by many. That in itself is proof that the ‘framework’ works. It’s more that it has become fragmented with the different systems all adding individual layers that they are wanting to bring together as we are duplicating effort in places.

Not precisely the same argument but very similar:
“Write once, publish everywhere” - Jeffrey Zeldman

First thought is you are correct in that when moving from separate systems to one big system, a structured design process that everyone uses is important. From past experience be nice, make suggestions and have information available when requested. And don’t do the I told you so later. The process will migrate to the change as more of the technicians see the need for the change, and not before.

Thanks for your thoughts michelle :slight_smile: