Introduction to Omni

This transcript document is associated with the first video, "Introduction", in the Using Omni CMS Udemy course.

Let's talk a bit about your websites. We don't really know what level you may be coming at, so just to demystify websites a little bit. Your website is not much more than a bunch of text documents organized into folders. Your web pages are basically just text documents, and the folders can help you organize your site's content. You may group together pages that are all related to the same programs or services, or things like, "Here's my folder of events, here's my folder of news items," those kinds of things. And you may also have folders that can collect various types of documents, images, includes, those kinds of things to give you some organization. Your folders can give your users an idea of what part of the website they're at, and can help you kind of organize your files, so you know where to go find things to update them.

We have a sample URL here of a TTU website. The main things to focus on in this, depts.ttu is the primary web server for TTU websites. Most of your sites are probably listed on depts.ttu.edu. We do have the main ttu.edu domain that some departments are on. There's also the cmsdev.ttu.edu, that's a development environment. If you're wanting to do some hardcore testing and development on your site, we can set that up for you so that you publish to CMS Dev without affecting your live website. The first thing after that is typically the site name. In this example URL, it's /itts. That's the Technology Support website. For many of our departments, the permission schemes are small enough so that if you can affect one page on a site, you can probably affect everything on that site. Some departments are large enough that they have multiple what we call "sub-sites" where permissions, you may have smaller permission groups there. Something like the Provost Office has lots of departments under the /provost umbrella, and each of those often have their own permission groups. Not necessarily true, but for smaller departments, depending on your permission scheme, you can probably edit everything on that site. What follows after the site name is. the folder structure to get to whatever page. So, for the sample URL here, we have "labs" or "/labs/atlc". There's a "labs" folder somewhere at the root of the site and within that some "atlc" folder. Then the "policies.php" is the actual page that we're going to work on, if that's the page that needs to be edited.

We can talk about visibility a bit. A page with no links to it is virtually invisible. We have this picture here depicts like a little cabin at the foot of a mountain next to a stream with a boat next to it. [stumbles over words] If you built this piece of real estate, if you built off this property, no one would know it's there unless you start advertising for it. It does still exist in the real world, someone could drive or walk to it. That's the same with your web page. If a web page doesn't have links to it, it does exist, it's fully public. Someone could get there if they just typed in the URL for it. But if you're not otherwise linking to it, the traffic will be pretty minimal. That helps you out in a couple of different ways. If you need to make edits to a page, especially if it's real complex edits, go ahead and just make a copy of that web page, and then make your edits to that copy. That copied version wouldn't be linked to from anywhere since you had just made it. You can freely do whatever you want to that page. Maybe don't write anything disparaging that could get you in trouble or anything on that site. Absolute worst case, put a message at the top saying, "Hey, this page is a test page, it's under construction," that kind of thing. But no one's going to be looking for "/index-1.php" or whatever, even if you rename it to something even more obscure. If you need to make edits, go ahead and make a copy of the page. No one's really going to know that it's there, especially if that page is only up for an hour, two hours, up to a week, whatever. Really, no one's going to find it.

The other side of that coin though, is if you want users to find your web pages, you need to link to them. Actually, for accessibility, you need to have a couple of different ways to get to your page, in case someone misses the first door, they can find the second one. You need to figure out how you want to link to your content, what are the other relevant pages on your site that would want to point to this web page, what are things that are related that have similar missions. Even reaching out to other departments around campus that are doing similar work, that's reaching similar audiences, have similar programs, finding those allies across campus and saying, "Hey, we have this resource. It looks like you have this resource. Can we link back and forth to each other to see a bit about how we can help each other out, rising tide with all boats situation?"

The final side of that is that deleting the links doesn't delete the page. You may remove a link from your web page, but the content is still there, the web page is still there, someone could still type it in. Now that you've marketed and advertised it, things like Google would have that page bookmarked. Users may have things bookmarked or they may just know the URLs, old social media posts or old newsletters may still contain those links. Deleting the link off of web page doesn't actually delete the page. You, in this case, you took down the advertising and destroyed the roads to get to your house, but the house still exists. You can still navigate to it. Whenever you have something that you want to remove, go ahead and delete that content, especially. We see this a lot with people saying, "Well, Google can find this old web page or Google can find this old document." Well, if it's still active on your site, it's still going to be there. Go ahead and delete content when it's not relevant anymore.

A few things to note with working in Omni. There are two different servers that we are updating. We have a staging server that is updated every time you hit "Save" within Omni or every time you upload content. A production server, the actual web server that is updated whenever you hit "Publish" within Omni. You're working on two different versions of files when you're working in Omni. The staging stuff is fully in Omni. You're file hosting as you're editing those. Once things are done and ready to go on the actual website, when you hit "Publish", that's what updates the actual website. You'll see this a lot. Sometimes you may be like, "Well, that change didn't come through or I uploaded this image but it's not on the website." When in doubt, go back and publish to make sure things are pushing through to the other web server.

The other thing I want to talk about here right now, take things one step at a time. You don't have to score a first down or a touchdown on the first play. You can slowly work your way up to it. Once you get working on your website, you'll be more comfortable in knowing what amount of work you can do at any given time while you're comfortable with doing so. This is something even I do. Start out your project, do a little bit of work, publish it, make sure that looks fine, go back, add more to it. Go back and fix things or go back and build on the next section. Publish that, make sure it looks good, go back, do the next thing. I'll do that all the time. If I'm working on something more complex, I start with what I'm comfortable with, publish it, make sure it works good, go back, do the next bit of the work. You don't have to do it all in one go. Piecing it out like that can make it a little bit easier to see where things go wrong whenever sometimes like, "Well, okay, I did this amount of work on this page, it's probably something in there that broke whatever happened." Take things one step at a time. Don't try to just write it all out perfectly your first time. You can slowly build into these things.

It's also a good idea to test your work in as many different environments as you can. HTML is a standard language, but everything can interpret it in a different way. We have a variety of screen sizes and devices that could be accessing your website. Trying things out on a desktop, a laptop, a tablet, a phone, multiple different browsers, different screen sizes, different screen orientations, different devices, different browsers, all of those things can impact how things are shown. Look at your analytics data, see the ways in which most of your sites are being accessed. If you're a very student heavy website, it might be that lots of your traffic is coming from mobile devices from phones, so you really want to make sure your site works for mobile devices. If you are more staff-focused, it's likely that most staff are using laptops or desktops from their work environments. Maybe skewing that a bit more towards Windows, desktops and laptops might be better. Ideally, your platform should work across all platforms, but you'd want to make sure you're specifically targeting for ones that your users are coming from.