Here at Jitbit we just love this, when a simple tiny little improvement can be a real benefit to both us and our customers.
Every Jitbit product has a "version history" page on our website, which is updated with a new record when a new version comes out. The update contains a version number, release date and a list of changes in this version (see an example - Macro Recorder version history)
Starting today, we are syndicating this release logs via RSS. This simple and obvious feature should have been added ages ago... Now, if a customer wants to be alerted of our new versions (without reading other Jitbit news) he simply subscribes to a feed on a product page. And if we want to broadcast a new version announcement, we don't have to write a news-article any more :-).
Why all software vendors LOVE feedback and WHAT kind of feedback they love Aug 22, 2007
Every single software company in the world, no matter if it is a giant corporation or a tiny one-man-band show, LOVE customer feedback. To be more precise, they love feature requests. We hunger for it.
I'm going to share a big secret. When someone suggests a feature request, he/she not only asks for a cool feature for himself. He also helps a software company make more money, obviously, since the requested features are most likely will be useful for ten other users, who are too lazy to post a support-note. You spend your own time to improve someone else's business. That's why I am always sincerely grateful to all users who kindly post their requests to us. Again, we hunger for it. We spend sleepless nights thinking, "how can I improve my software X?", and there you are - with a feature request. Free of charge. THANK YOU.
Moreover, feature-adding is typically a pleasant job. Unlike some anoying elusive bug which shows up, say, only under Vista running an AMD 64bit processor and an onboard video card (oh yes, we actually had the issue, a real pain in the a**).
Keep that in mind. And next time when you request a feature from someone without an answer - run, don't walk.
I'm going to share a big secret. When someone suggests a feature request, he/she not only asks for a cool feature for himself. He also helps a software company make more money, obviously, since the requested features are most likely will be useful for ten other users, who are too lazy to post a support-note. You spend your own time to improve someone else's business. That's why I am always sincerely grateful to all users who kindly post their requests to us. Again, we hunger for it. We spend sleepless nights thinking, "how can I improve my software X?", and there you are - with a feature request. Free of charge. THANK YOU.
Moreover, feature-adding is typically a pleasant job. Unlike some anoying elusive bug which shows up, say, only under Vista running an AMD 64bit processor and an onboard video card (oh yes, we actually had the issue, a real pain in the a**).
Keep that in mind. And next time when you request a feature from someone without an answer - run, don't walk.
Bug fixing Aug 17, 2007
Now this is funny. Recently a couple of users have reported, that the online demo of our HelpDesk software was down, keeping everyone from logging in. After some investigation it appeared that somebody was testing the HelpDesk's administrative functions. Specifically... resetting the passwords!
We have also located (and fixed) a very shameful bug in our MailJet software. This is rather sad than funny: under certain conditions, when sending personalized emails, the program was always placing the name of the first recipient into the email, no matter how many recipients there are. Many thanks to Michael from Bloombit Software for pointing us at this (and suggesting some very nice other features). The updated version is already published on our website.
We have also located (and fixed) a very shameful bug in our MailJet software. This is rather sad than funny: under certain conditions, when sending personalized emails, the program was always placing the name of the first recipient into the email, no matter how many recipients there are. Many thanks to Michael from Bloombit Software for pointing us at this (and suggesting some very nice other features). The updated version is already published on our website.
Help-Desk: the making of Aug 15, 2007
Just a small announcement on what's coming in the next version of our ASP.NET Help-Desk software that we hope to release in the next few days (fingers crossed):
- XHTML-conformance
- CSS optimizations
- Knowledge-Base will be accessible to non-authenticated users
- some more general improvements
UPDATE: a user on our forum has suggested to store the user's first/last names along with the login-name. This will also be added to the release.
Macro Recorder: new timing architecture Aug 10, 2007
Here is another post in the series of "the making of" posts where I speak a bit about what we're doing on the next versions of our products.
Today we have looked at our Macro Recorder and decided to abandon the idea, that every command/event in a macro must have a "timeout" characteristic.
This was stupid. We admit it. It's a legacy feature, left from the days when Macro Recorder was just a tiny little mouse-recorder/player tool, without all this "if-then-else-goto-repeat" stuff. Actually sometimes I miss those happy days... ;)
Now, this timeout field was supposed to mean "how many milliseconds to wait, before executing the command". It was very confusing for a new user to understand, why does Macro Recorder assign this "timeout" to the recorded commands, instead of simply inserting a DELAY command before it? It also made the text of a saved macro look obscure. That's why we are getting rid of it. No more timeouts. If previously a saved macro would look like this:
Also we have found a small error in the exe-compiler, which may lead to incorrect GOTO-command processing. Many thanks to Henrich Eckhardt for reporting!
Today we have looked at our Macro Recorder and decided to abandon the idea, that every command/event in a macro must have a "timeout" characteristic.
This was stupid. We admit it. It's a legacy feature, left from the days when Macro Recorder was just a tiny little mouse-recorder/player tool, without all this "if-then-else-goto-repeat" stuff. Actually sometimes I miss those happy days... ;)
Now, this timeout field was supposed to mean "how many milliseconds to wait, before executing the command". It was very confusing for a new user to understand, why does Macro Recorder assign this "timeout" to the recorded commands, instead of simply inserting a DELAY command before it? It also made the text of a saved macro look obscure. That's why we are getting rid of it. No more timeouts. If previously a saved macro would look like this:
0 : Keyboard : D : KeyDownFrom now on a saved macro will look like this:
14: Keyboard : D : KeyUp
Keyboard : D : KeyDownLooks more human-readable, right?
DELAY : 14
Keyboard : D : KeyUp
Also we have found a small error in the exe-compiler, which may lead to incorrect GOTO-command processing. Many thanks to Henrich Eckhardt for reporting!
Why we still use VB6 for some projects Aug 9, 2007
I've been asked several times, what programming language do we use in our development. Here it is:
- C# for ASP.NET applications including Help-Desk, CRM and AspNetForum
- C++ and VB6 for desktop apps like Macro Recorder or AutoText - AKA "Text Expander for Windows"
- VB6 is the only .NET-like rapid development tool, that produces small native Win32 executables (that run fine on Vista, by the way, of course, with some hacks applied)
- VB6 is so COM-friendly
- VB6 is widely supported by the community and the Internet is full of articles, manuals, hints and tricks
- VB6 is rapid, allows to concentrate on the end-user's needs instead of memory management, marshalling and stuff
With VB6 I do miss the "true OOP" features like inheritance, or polymorphism. In fact, ages ago I was a "hardcore" C++ developer, who despised VB6. But now I'm not going back to C++/MFC. Because I'm really spoilt by rapid .NET development. I wish there was a "C# 6", but there isn't, so we stick to VB6. It is almost dead, it will be totally unsupported after 2008, but... it works!
You may ask, why not use .NET to build end-user tools?
- I believe that our customers need small and fast native executables, that do not require a 25 megs download from Microsoft, and run on older versions of Windows
- .NET apps are way hard to protect from reverse engineering
- I don't like the mess with different .NET-framework versions (1.1, 2.0, 3.0 and now even 3.5) that might confuse our customer
- Basically, .NET is good for developers, .NET is OK for enterprise web-applications, web-services, some complicated distributed database-driven enterprise apps etc. etc., but not for end-user utilities.
I guess when the VB6 is really truly dead, we will think of moving to Delphi, maybe. And again, I wish there was a native compiler for C#... Sigh...
UPDATE: thanks for commenting, mates! We do think of migrating to Delphi. But as far as I know, it has no support for Unicode. Correct me if I'm wrong.
Help-Desk demo Aug 8, 2007
We have just launched an online demo of Jitbit's Web-based Help-Desk software. Use "admin/admin" to log in as an administrator, or "client/client" to log in as a regular user.
I just realized, that when I choose a web-app or a component for myself, I never even look at the ones that have no online demos. Offering a server-side product as a download only, is not a good idea since few system administrators will ever install something on their production server for evaluation purposes.
I just realized, that when I choose a web-app or a component for myself, I never even look at the ones that have no online demos. Offering a server-side product as a download only, is not a good idea since few system administrators will ever install something on their production server for evaluation purposes.
New website look Aug 3, 2007
As you can see, our website has a new look. It took us almost 2 days to set it up. 1 to rewrite our HTML/CSS code, and 1 to install it - and discover a dozen new bugs :-)
Macro Recorder: the making of Aug 2, 2007
Now, with this blog, I finally have a place to whine about our everyday struggle for new versions. So, this post marks the beginning of a series of "the making of" posts which will tell you a bit about what we're doing on the next versions of our software.
So, if anyone is interested what's behind those dry "what's new" lists, here we go.
It occurred to me the other day, that our Macro Recorder has an "IF" statement, but there's no "ELSE" statement. How dumb were we not to add this feature? So I got filled with enthusiasm (Dan, I promise, I will never call this late again) and we started coding right away. After a while I realized that adding "else" would be more complex than I thought, since I will have to rewrite all macro-command stack processing... At the same time I found a general bug with IF-statements which can result in improper behaviour. After all, what I thought would be a 15-minutes job resulted in 3 sleepless nights.
But now it is almost finished. I even decided to add another type of IF-statement - "IF Window Exists" - to this release. I'm pretty sure it will take me no more than 15 minutes...
So, if anyone is interested what's behind those dry "what's new" lists, here we go.
It occurred to me the other day, that our Macro Recorder has an "IF" statement, but there's no "ELSE" statement. How dumb were we not to add this feature? So I got filled with enthusiasm (Dan, I promise, I will never call this late again) and we started coding right away. After a while I realized that adding "else" would be more complex than I thought, since I will have to rewrite all macro-command stack processing... At the same time I found a general bug with IF-statements which can result in improper behaviour. After all, what I thought would be a 15-minutes job resulted in 3 sleepless nights.
But now it is almost finished. I even decided to add another type of IF-statement - "IF Window Exists" - to this release. I'm pretty sure it will take me no more than 15 minutes...