Biggest Mistake
Sitefinity Developers make.
Introduction
Its not hard to spot a design that was created by a developer. Almost every Windows Form App up until 2010 suffered that horific left side brian effort. Thankfully today we often have a dedicated UI/UX designer sorting that out but even if you have no responsibity around what the front end pages look like you still have a major UX responsibility to ensure a successful project.
You have an award-winning look and feel. The site is 'A' grade in performance. Functionality is deemed 'the new funk' and the company's marketeers are happy. Still, the company IT team don't hold you in the same light and are not singing your praises. What could be the issue?
The Mistake
You didn't think about the 'User Experience' of the content editors!
Perhaps you have created such a jumble of layouts and widgets that they need a flow chart and training to work out what combinations work to achieve page displays. Maybe there is a vast complication around the content modules and what widgets pull what data from where. Complications over when content updates will actually appear in the live site due to cache. Or the page editing experience looks nothing like what the front end is and its endless trial and error to make a change. This then leads to endless calls for help to the developers and your name is mud!
I am by no means a UX professional but it is something I think about and I suggest you do as well. I will list a few of the things that go through my mind. Still, truth be told, after several months I sometimes look at how things have grown and thought to myself how different I would have done things if I had known all those 'enhancements' that came along after the fact. So, it's not always easy to get it right at the start but it is worth trying to.
My first suggestion, work with the client content editors. Here I mean the actual people who will do the work and discuss not only the now but the future. It's not possible to totally foresee everything but you are more likely to get it right or have the future catered for if you talk about it now.
The other important thing you learn is an understanding of the actual experience and skillset they have.
I recall a discussion about how to program something and the people to use. One argument was 'They have 10 years programming experience.' The other, 'No, they have one year's experience programming and have been doing the same thing for 9 years'.
Your Customers
Assess and understand your content editors. They may not be the website's customers, but from a CMS point of view, they are definitely your customers. What is their current experience? What do you think they can learn and be taught. What is going to be the effort to maintain data in modules? Creating and editing pages. Think about how often you want them calling you for help.
If there is no way they will understand HTML, CSS and JavaScript then make sure they don't have to deal with it.
There is no point in giving them a plane if they are not able to fly it. Better to give them tools to book a plane flight.
Make sure every field is valid and relevant. This applies to your custom modules and fields and widget designers. If a field is not used anymore, clean it up and get it deleted.
When making widget designer forms, look to hide fields that are not relevant for different view displays you may have created. You can use the Angular 'ng-hide' or 'ng-show' to hide those properties. If the property is not related to the view don't confuse the user with it being there. Consider splitting up options with tabs such as a tab for content display options and a tab for picture display options.
Too many 'content placeholder' sections can make for messy page management and widgets being dropped in the wrong place. Think about sections that could be 'hard-coded'. Company logo for instance. If the company decides to change their logo, name or phone number then you will need a code deploy, but how often is that going to happen and if it does, it sounds like part of a much larger business event. Talk about this with your client.
Put a lot of thought into how the site will be developed and deployed across environments and implement it early. The cotent editors may be part of QA and having confidence in how this works and how they are involved is a good thing. As soon as you have your empty Sitefinity project running, check it in and get it deployed to Dev, to QA. You want to make sure that this process is seamless and working early on. If everyone is confident in the deploy process life is a lot easier. And you never want to be deploying to the production servers for the first time two days before the marketing launch date.
If you have a good deployment process then you should be able to get a call in the morning, make that code change to your widget, check it in and head off to that boozy lunch. Meanwhile, the computers and client automatically push it through the environments via CI, testing and signing it off through to production that afternoon.
Try and foresee and map out as many 'widgets' as practical at the time. You want to keep the number\varity of these down and avoid needing to create new widget controls for every new requirement. Think about how to group widgets into one widget with multiple display options. For example, a 'title' may have four different looks but they are all in the one 'Title' widget that has multiple view options.
Work strongly with your front end developer at the start. Make sure they understand how the Sitefinity base page, layouts and widgets work together. Know how the content editor will create a page using them. You want to keep those layout styles separate and independent from widgets as best as you can. And don't have any classes assigned to the element. That will just ruin your backend page editing experience.
Consider using Sitefinity roles to avoid every backend user being an administrator. If they can't see or access content and settings then they can't break things and are less likely to be confused by it all. They also won't be as intimidated or fearful of it.
Have a very clear understanding of any and all caching that you implement and use. Don't over complicate it and be able to explain it to the customer.
Put a lot of effort into how images are managed. It's not uncommon, you get called back for rubbish site performance issues to find the primary cause are 3MB sized images being served everywhere. Create folders as opposed to dumping everything in the 'Default' folder. Look to apply the built-in size limits. When adding related images to content items, think about providing instructions for the size expectations in the description field.
Just because you can upload videos to Sitefinity. Don't. Use Vimeo, You Tube or some other purpose built video streaming service. IIS, ASP.NET, SQL is not designed to stream videos.
My last bit of advice, keep releasing and have the editors review and use your changes. Get them involved in the development progress so that they can provide feedback and learn things along the way. Avoid dumping three months of finished work on them.
Thanks for reading and feel free to comment - Darrin Robertson
If I was really helpful and you would buy me a coffee if you could, yay! You can.
Leave a comment Load more commentsMake a Comment