Innovating WedgeDesk

I’ve talked about SimpleDesk before, and given that I’m currently moving things towards Wedge, it seemed inevitable that I’d start working on a port, or rewrite, and over the last few days I’ve been spending time on it, dubbed WedgeDesk.

Just wanted to add a few words on it, and things I’ve already found.

I’m not entirely sure that I’m going to be doing too much innovation this time round, maybe in the future. The area of helpdesks, and ticket tracking stuff in general, is fairly well established and it’s not exactly a rampant hot bed of innovation – people want systems that are familiar and comfortable, rather than wildly off the scale.

That’s not to say that I won’t spend time following my usual processes, trying to figure out what kinds of improvements I can do, as well as iterations on the concepts currently in use.

Interestingly, though, the first things I’ve been doing – other than fixing the binding and interaction between the code and the base (like fixing markup and layout code as well) – is looking less at what I can add, and more about what I can remove.

As it is, I’ve already removed two or three minor features and looking at replacing some of the other features with improved versions.

One thing that does occur to me, though, I’m finding myself more free to make changes; already I’ve modified the core layout as well, taking out some of the vertical lines and borders, and re-laying the content, not only for consistence with Wedge itself, but laying the foundations for other things.

What is also quite interesting is noting that there’s an awful lot of code being removed for things that WedgeDesk doesn’t have to manage for itself any more, I found a surprising amount of code under the hood that I didn’t even remember writing, whose purpose was primarily to get round certain limitations in the SMF core, though I would think it unfair to lay the blame on SMF’s development for them; they’re limitations that most add-ons to SMF would never likely encounter, and even if they were, there are many more usual and ‘expected’ solutions to the problems at hand.

For example, the one that really sticks out currently is that of language files. SMF does provide a language editor of sorts, which is capable of examining all the language files in the main folder, plus those for any theme that has its own language files – which for most cases will be sufficient.

For extensions, however, that use their own language file(s), they either have to put their language files into the main folder, or just have their language files outside.

The usual or expected solution is to put them in the main folder, which means it’s harder to find them, and the files have to be added one by one (to be reliable), which puts more effort on the package maintainer.

So, I took an alternative route, because that solution didn’t feel right. I put all the files in one folder, but then proceeded to add that folder to the list of possibles in the language editor, which circumvented both the tidiness/maintenance issue as well as the fact that it makes it nicer and tidier for editing purposes.

As far as I know SimpleDesk was the first to do it, though I know it isn’t the only one – but it means I’ve got something that I can add to Wedge to provide support more widely for doing this – and that will probably be a little more innovative.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.