Umbraco Preview: Are my changes live or not?

This post is based on the following Umbraco setup.

• Umbraco v7.2
• Azure Sql Server - Web Edition

Background

Preview in Umbraco lets you quickly see how your page will look on different devices. It allows content editors to switch between different devices previews and see how their content will display on a number of common device sized before making their changes live. Recently I had a client raise a few concerns about how the preview functionality worked and so this post is for all those who have to do the same in the future.

Where's my preview button?

The first problem the client had was not being able to see a preview button on their newly created pages. In order to preview content, the content must first be saved. Once saved (but not necessarily published) the preview button will appear in Umbraco.

Is it live or not!

When a content editor clicks preview they are able to see what the website will look like before it is published and available to all website members. Umbraco does this by setting a cookie in the user’s browser which is persisted until they log out of the CMS. This caused great confusion with my client who was concerned the preview functionality was broken. They had made changes and previewed them in the cms. They had then visited the main site as a member, while still logged in to the CMS. As the preview cookie had not been cleared they could see their unpublished changes on the live site. Of course the changes were not live, and once they logged out of Umbraco, normal service was resumed. However, we now always advise....

Once content editors have finished previewing content, they should always logout of Umbraco to ensure they are seeing live content rather than preview content.

Talking with tech leads: James Gaisford

At the end of last year I was offered the role of Head of development at my company. Having been a reluctant senior developer, I was a little reluctant to take the role, but after some careful consideration I accepted the offer. As with previous career challenges, I sought advice and guidance from the internet. But the best steer came from an unlikely source - a tweet from Martin Fowler

.@wilpannell The book on being a tech lead is by @patkua https://t.co/BoyWVS6F0e

— Martin Fowler (@martinfowler) December 20, 2014

The book referred to in the tweet is called "Talking with tech leads" and it is a must read for all developers thrust into the strange and unfamiliar world of leading a technical team. The book takes the form of interviews with a number of tech leads, asking a core set of questions particularly around significant challenges faced and how they balance the technical and non-technical worlds.

So, after my first six months as a tech lead, I present my answers to those same core questions asked in the book.

What should a Tech Lead focus on and why?

Solving problems without coding. As a developer your core skill is to be able to solve problems by coding. This is a skill that has been honed over many years. It is very tempting as a developer, new to the tech lead role, to offer only code based solutions to customer problems, but stop. and think if there could be a non-code based solution to the problem presented. Pushing back on client requirements? Negotiating with project managers to get additional resource? Scrutinizing client requirement documents? Writing tight functional specifications. All of these and other non-code based solutions can come to your rescue. Expand you toolbox. 

What has been your biggest challenge as a Tech Lead?

Don't over-commit.... and delegate. With a new role comes a lot of new responsibility. This means a lot more work. Depending on the set up in your company, there may be an expectation that you still perform some or all of your previous role's responsibilities as well. You will be asked to do a lot, but don't be afraid to push back, to say no. You may have a team to whom you can delegate some of your work to. Don't be afraid to use them. No one will think you are incapable, slacking off, or being lazy. In fact, if the team is good, they will relish the challenge.... just don't over do it.

Any time-management tips?

Get in early. Process emails. Work out a plan of attack for the day. Create a simple list using a pen and paper - I know, it's pretty revolutionary - in priority order to work through. Close the inbox. Cross through items on your list. Its amazing how that simple process can help feel like you are "winning" t the day. Decline any meetings invites that aren't relevant. And for those meetings you have to go to, make sure there is an agenda with a clear purpose, and any actions noted.

How do you strike the right balance between writing code and dealing with other issues?

This is really tough. The thing that makes this easier, is knowing you have a team of people who are as good, if not better, than you at coding. So, there is no need to worry that the code will get written. Of course you should always try and devote at least some time in your week to writing code, but nothing that will take longer than a day and nothing that would jeopardise the project if you had to drop it.... which you most likely will.