IT reporting website for every day users
-
@wirestyle22 said in IT reporting website for every day users:
@stacksofplates I think an interesting project would be to create a shared directory that Ansible pulled from to create pages on the website per day and allow it to automatically organize the website. It seems like it would be possible to do. Just a thought.
If you're going to go to that much work, just have a script that checks your actual monitoring and posts human readable outputs to Grafana.
-
@coliver said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
Dokuwiki is the right answer because it is so much simpler and no one that can't format should ever be allowed to give a status (it means that they are too stupid to understand the status) and no one should be formatting anything anyway when giving a status, so making it easier to screw up makes no sense
This. No requirements for a backend other then a webserver makes it portable and easy to use.
I'd personally use Hugo or Asciidoctor for it. Just have the tool build the site and deploy it.
-
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
-
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
-
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
It doesn't have to be publically viewable. But I'd want everyone to be able to see it if they wanted to. There should be a section for current issues. And then when they are fixed moved to an archived area. That way there isn't any confusion for anyone if it's a current situation or not. And it's transparent.
-
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
It doesn't have to be publically viewable. But I'd want everyone to be able to see it if they wanted to. There should be a section for current issues. And then when they are fixed moved to an archived area. That way there isn't any confusion for anyone if it's a current situation or not. And it's transparent.
For private for IT, then yeah, I'd want history. Could be very useful.
-
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
It doesn't have to be publically viewable. But I'd want everyone to be able to see it if they wanted to. There should be a section for current issues. And then when they are fixed moved to an archived area. That way there isn't any confusion for anyone if it's a current situation or not. And it's transparent.
For private for IT, then yeah, I'd want history. Could be very useful.
I'd even make it open for non IT people. But it doesnt matter at this point. It should be a function of whatever tool you're using because it has value either way.
-
Honestly, what I'm thinking is a PowerShell GUI script that has a few simple fields like server/service, status, notes... Which simply outputs it to an html page. And also a button to clear/delete entries.
Lots of options. Maybe even list all services and the status... Stored in a csv, read and manipulated by the script GUI, outputted to a web page.
-
Something like https://cachethq.io ?
-
So I'd personally use Hugo or Asciidoctor like I mentioned, that way it's version controlled and can be built with a pipeline. But if you want stupid simple, Grav would work really well. There is a git sync plugin to use git for versioning, but if you don't want to set that up it's stupid simple to back up, just back up the directory. Here's a demo I threw up in Docker.
You get the nice admin page with WYSIWYG editing. If you don't want that, you can write raw markdown also.
It's an awesome tool with plugins and some nice themes.
-
Also as a side note, if you hate Powerpoint like I do, it has a presentation plugin that doesn't look too bad.
-
Grav looks really cool.
-
@coliver said in IT reporting website for every day users:
Grav looks really cool.
Yeah it's a pretty awesome tool. It's one of the rare ones that has great functionality and also looks nice.
-
@stacksofplates This looks fantastic. Thanks
