04-23-2015, 09:06 AM
(This post was last modified: 12-06-2016, 08:11 PM by Dean Roddey.)
<5.0 is released, so this thread is closed>
So, I'll get 4.7 out today (or maybe tomorrow.) But, in the meantime, I figured I'd go ahead and start the 5.0 discussion thread and discuss what is on the plate. I'll sticky thing guy after 4.7 is out and unstickied.
It's clear that the biggest single issue we have, well maybe two very related issues, is that product is too complex/slash too hard to user. This is true both for DIYers and professional installers. And, very closely related, folks don't like the UI because it doesn't have a native Windows UI feel. A lot of the complexity isn't the actual complexity of the underlying product, but just less than optimal presentation of the content for manipulation, and also lack of a coherent, single documentation interface.
These things are going to be dealt with for 5.0. This is going to be a brutal effort, at least for me. It is going to take all I have to get this done in a reasonable time frame, because it's going to effectively mean rewriting all the GUI applications. It won't actually be that bad, in that there is much code that can be stolen from the existing stuff, and more stuff will be incorporated into a single administrative interface instead of being separate programs.
But still, it's going to be a slog. We will have to stay VERY focused on this effort, and can't afford any distractions. So just fair warning that, unless it's something that brings in immediate much needed revenues, or some obvious bug, it's not likely to get done for the new good number of months. This is critical to the viability of the product and without this any other stuff will be come moot.
Obviously, since I'm going to essentially be starting over on the GUI, it also offers an opportunity to make some fundamental improvements to the back end, both to better support the superior user interface, and to fix some things that have long been sub-optimal. I will though avoid "2.0 Syndrome". The point of this isn't to try to create Nirvana in one pass, and take on so much it never gets finished. It's to get a vastly improved, standards compliant, easier to understand user interface for the existing system.
The other thing that we have to make at least a start on is the HTML5 client. Luckily that doesn't require any GUI programs to be working in order for me to start on. That's important because, once I start this, I'm going to break all of the GUI apps until I get them rebuilt. And, the two will provide some relief from each other I guess.
All this means that I will have to split the code and make any fixes that absolutely have to be done in two places. At least in non-GUI code. For GUI code, it's probably only relevant to the old stuff since the new stuff will be so different. So we want to keep changes to an absolute minimum, since that's always more dangerous and time consuming.
So if we have to, we can do a 4.7.1 with some small fixes, but no more than that. Driver work will also have to take a back seat during this period as well, unless it's providing immediate revenues. That won't be optimal, but ultimately it's more important to have a product people will use, that to have more drivers that people won't use.
In the end, it will result in a product that is vastly superior for everyone, and (hopefully) a lot more revenues that will let us grow and take care of many more of your concerns than is possible now (and within the context of a much better user experience.)
BTW, the purpose here is not to make a super-simplified (aka very limited) UI. That is something that might come afterwards for a super-low end version of the product. This GUI I'm talking about here will support all of the existing functionality, so it won't remove anything that is currently possible. It'll just present it far better and make it much easier to access, with more targeted help, more 'wizardy' stuff and all that.
I've already been working for a couple weeks on a new set of Windowing classes, wrapping the standard Windows controls. I've had to hold my nose a bit because it's not nearly as clean as having my own, fully integrated controls. But, of course, I get a boatload of functionality for vastly less effort. I've already set up a basic class hierarchy and got basic implementations of buttons, static text (single/multi), text editor, sliders, images, combo boxes, simple list boxes, multi-column list boxes with headers, frame windows, check boxes, calendar, and progress bars. I'll add more functionality to them as required.
I'm working on the tree view, which will be a big thing in the new scheme of course, so that we can have a tabbed application where each tab is a standard iconified representation of whatever that tab contains (drivers, users, events, etc...) It'll all be more drag and drop oriented and object oriented (right click on a thing to modify it) and less modal. And, since it just uses standard controls, and makes no attempt to customize them, they will adapt to whatever look and feel is in force on the user's system.
I may use the IV to do some pre-visualization of how it might look. It'll require a good bit of custom graphics work since we'll want to have nice graphics for everything. The pre-viz will also help work out how well the graphics are working.
Oh, and the other thing is that the new HTML documentation system I posted some early info about will become the new documentation system. It'll get everything into one hyperlinked, structured document that can be used from the web site or locally, and that can be invoked from dialogs or applications, to get help on whatever that particular dialog or application is about. That in and of itself will be a lot of work, though just grunt work, not technically complex. And of course a lot of it can't be started until we know what it is we are going to be documenting. Some stuff can get moved over early on, that won't be affected by the GUI stuff, like CML, PDL, drivers, device classes, etc...
So, anyhoo, there it is. I'm some will be happy, some will be not so happy, with this course. But it's what we've got to do. Everyone will benefit in the end, directly or indirectly. As you can imagine, if I even just live through this it will be somewhat miraculous, so there will be little room for distraction, even if that means leaving some annoyances unattended in the short term, in particular if those annoyances are GUI related and will become irrelevant in 5.0 because that code doesn't exist anymore.
So, I'll get 4.7 out today (or maybe tomorrow.) But, in the meantime, I figured I'd go ahead and start the 5.0 discussion thread and discuss what is on the plate. I'll sticky thing guy after 4.7 is out and unstickied.
It's clear that the biggest single issue we have, well maybe two very related issues, is that product is too complex/slash too hard to user. This is true both for DIYers and professional installers. And, very closely related, folks don't like the UI because it doesn't have a native Windows UI feel. A lot of the complexity isn't the actual complexity of the underlying product, but just less than optimal presentation of the content for manipulation, and also lack of a coherent, single documentation interface.
These things are going to be dealt with for 5.0. This is going to be a brutal effort, at least for me. It is going to take all I have to get this done in a reasonable time frame, because it's going to effectively mean rewriting all the GUI applications. It won't actually be that bad, in that there is much code that can be stolen from the existing stuff, and more stuff will be incorporated into a single administrative interface instead of being separate programs.
But still, it's going to be a slog. We will have to stay VERY focused on this effort, and can't afford any distractions. So just fair warning that, unless it's something that brings in immediate much needed revenues, or some obvious bug, it's not likely to get done for the new good number of months. This is critical to the viability of the product and without this any other stuff will be come moot.
Obviously, since I'm going to essentially be starting over on the GUI, it also offers an opportunity to make some fundamental improvements to the back end, both to better support the superior user interface, and to fix some things that have long been sub-optimal. I will though avoid "2.0 Syndrome". The point of this isn't to try to create Nirvana in one pass, and take on so much it never gets finished. It's to get a vastly improved, standards compliant, easier to understand user interface for the existing system.
The other thing that we have to make at least a start on is the HTML5 client. Luckily that doesn't require any GUI programs to be working in order for me to start on. That's important because, once I start this, I'm going to break all of the GUI apps until I get them rebuilt. And, the two will provide some relief from each other I guess.
All this means that I will have to split the code and make any fixes that absolutely have to be done in two places. At least in non-GUI code. For GUI code, it's probably only relevant to the old stuff since the new stuff will be so different. So we want to keep changes to an absolute minimum, since that's always more dangerous and time consuming.
So if we have to, we can do a 4.7.1 with some small fixes, but no more than that. Driver work will also have to take a back seat during this period as well, unless it's providing immediate revenues. That won't be optimal, but ultimately it's more important to have a product people will use, that to have more drivers that people won't use.
In the end, it will result in a product that is vastly superior for everyone, and (hopefully) a lot more revenues that will let us grow and take care of many more of your concerns than is possible now (and within the context of a much better user experience.)
BTW, the purpose here is not to make a super-simplified (aka very limited) UI. That is something that might come afterwards for a super-low end version of the product. This GUI I'm talking about here will support all of the existing functionality, so it won't remove anything that is currently possible. It'll just present it far better and make it much easier to access, with more targeted help, more 'wizardy' stuff and all that.
I've already been working for a couple weeks on a new set of Windowing classes, wrapping the standard Windows controls. I've had to hold my nose a bit because it's not nearly as clean as having my own, fully integrated controls. But, of course, I get a boatload of functionality for vastly less effort. I've already set up a basic class hierarchy and got basic implementations of buttons, static text (single/multi), text editor, sliders, images, combo boxes, simple list boxes, multi-column list boxes with headers, frame windows, check boxes, calendar, and progress bars. I'll add more functionality to them as required.
I'm working on the tree view, which will be a big thing in the new scheme of course, so that we can have a tabbed application where each tab is a standard iconified representation of whatever that tab contains (drivers, users, events, etc...) It'll all be more drag and drop oriented and object oriented (right click on a thing to modify it) and less modal. And, since it just uses standard controls, and makes no attempt to customize them, they will adapt to whatever look and feel is in force on the user's system.
I may use the IV to do some pre-visualization of how it might look. It'll require a good bit of custom graphics work since we'll want to have nice graphics for everything. The pre-viz will also help work out how well the graphics are working.
Oh, and the other thing is that the new HTML documentation system I posted some early info about will become the new documentation system. It'll get everything into one hyperlinked, structured document that can be used from the web site or locally, and that can be invoked from dialogs or applications, to get help on whatever that particular dialog or application is about. That in and of itself will be a lot of work, though just grunt work, not technically complex. And of course a lot of it can't be started until we know what it is we are going to be documenting. Some stuff can get moved over early on, that won't be affected by the GUI stuff, like CML, PDL, drivers, device classes, etc...
So, anyhoo, there it is. I'm some will be happy, some will be not so happy, with this course. But it's what we've got to do. Everyone will benefit in the end, directly or indirectly. As you can imagine, if I even just live through this it will be somewhat miraculous, so there will be little room for distraction, even if that means leaving some annoyances unattended in the short term, in particular if those annoyances are GUI related and will become irrelevant in 5.0 because that code doesn't exist anymore.
Dean Roddey
Explorans limites defectum
Explorans limites defectum
