Over the past 5 years one of the solutions I've been working on has collected a lot of layouts that I think are no longer used. Are there some best practices to handle this?
In the past I've put big red letters on the screen saying the layout will be removed and then ask users to let me know how they got there, but I don't like relying on user reporting so I'm planning on building out something to track last visits on layouts.
I can use 2EmpowerFM to search for any scripts that go to those layouts, but that won't catch if there's a button somewhere that simply says "go to layout". Is there some way with a DDR or FMPerception or something can help me find "dead" layouts that haven't been visited in months?
Right now I'm thinking of running a script OnLayoutEnter to track last visit and who it was. Things I'm mulling over:
Do I group this in with my regular errors, or have a separate table? I'm leaning towards separate table since the data is actually fairly different.
What data do I track? I think just username, timestamp, layoutName
I think I should track all visits, not just latest.
Do I add this script to EVERY layout, or just the ones I think are no longer used? Or maybe all layouts except the 4-5 most popular layouts, since even little slowdowns add up when used hundreds of times a day.
Is there some smarter/more automated way to do this globally?
Please let me know if there's a smarter/faster way.
...maybe not a smarter or better way but having experienced this on a clients big solution with hundreds of layouts we put a big orange rectangle over the content that covered almost everything and on top of that a button that triggered a mail being sent to the dev-team. Therein the user had the opportunity to explain why she would like to use the depricated interface. We only received 20-30 mails and could serve all needs with newer interfaces.
Using a tool like BaseX you can query the DDR for a list of layouts that are being called in scripts and buttons. That may generate false positives. Your own idea, and @harvest's idea both seem very practical.
Re: "running a script OnLayoutEnter to track last visit and who it was"
That was my thought. I would keep track of that by creating a separate utility table called, say, traffic, and having that script create a new record to store the user data. The data you gather could be captured in one or more variables in the script. If you then set each field in the utility table to auto-enter those variables, then all you would need to do is to create a new record, and everything will be auto-entered, as long as the record is created by that script.
You could run that script on any layout you are considering removing. After a month or so you should have some useful feedback to help you decide what to do.
I, too, use auto-enter $variables for all of my "history-type" tables. It's a very clean way to work. Once the $vars are populated, just Create New Record and you're set.
Plus, any such work is done on blank form layouts (off-screen) so nothing gets loaded or flickers for the user on the layout their working.
Great thanks! Just added the separate utility table and am prototyping with half a dozen layouts. I put a big ugly warning on the screen as someone suggested and log every visit and then dumped them in a folder date-stamped for 3 months out and I'll check them then.
I agree, another happy user of FmPerception & FMComparison. Also no affiliation.
You could use a backup copy and remove the layouts completely ... then run a DDR and inspect for errors.
This may seem a little crazy, but could just remove the layout in the Production (aka Live) file, then see if/when people complain! It all depends on your client - will they agree to trade of the "clean-up" for the odd time when someone gets an error, how fast you can re-deploy the layout if it is in fact needed, how many users, etc.