Goldenseal Pro Design – Page 2

Links (May 4)

Our accounting/estimating software stores all sorts of info for your company. There are 18 types of accounts: customers, projects, employees, vendors, subs, bank accounts and a few others. Also 35 business transactions for estimating, accounting and project management: estimates, purchases, sales and many more. Most of them link to other records. For example, a Material Purchase has a supplier, a job account, a payment transaction, and maybe some cost items. Also, payment terms and a few other details.

You may want to take a peek at those linked items. Our software gets you there via commands in the View menu, or buttons in the record layout. Smart fields and table rows also have links. All of them open a record window that shows whatever you clicked on.

Accounts also have buttons to create new linked records: purchases from a vendor, sales or estimates for a customer, etc. All that linkety-linking makes your data more useful.

This past week, our staff worked on the links interface. We put it off until near the end because it’s important, and a dilemma.

Goldenseal uses a different window for each type of record. To show a link, it simply opens a new window, or brings an existing one to the front. That part is easy, but the multi-window setup has some basic flaws. Windows accumulate all over the screen. It’s easy to leave half-finished records somewhere in the clutter. Eventually the mess will drive you nuts, until you tidy up and close them.

The multi-window problem is even worse for Windows OS. That has a big Goldenseal window, with record windows inside it. It’s all because MS Windows puts a menu bar on each app window rather than at screen top. The window-in-window interface is the least bad option.

TurtleSoft Pro has a different design: just one window for everything. It has a tool bar, an outline view and tabs. The new look has much easier navigation. It solves the clutter problem. In general it’s pretty nifty. One-window apps are the trend these days, with buttons instead of menu commands. We are going with the flow.

The one-window setup does have a design problem: how do we show links?

We can’t put them in a tab. That was our first attempt. If the new tab jumps to the front, it hides the one you just clicked. If not, you have to click the correct tab to see it. One is annoying, the other is awkward and useless.

The new accounting app already has the option to show some records in separate windows. It’s there for die-hard Goldenseal fans who hate the tabbed window, or for anyone who wants to see two things at the same time. We tried that to show links, and it seemed decent.

What if the link is already in a tab? The solution was to move it out of the tab bar and into a new window.

What if you click a link from a separate window? For now it makes another separate window. That may bring back the clutter problem. Maybe we should add it to the tab panel, instead. It will take some real-world testing to find the best approach.

Another option is to use a temporary movable modal dialog: show one record until you click OK or Cancel. We already do that for lists. It may be the best solution for accounts and transactions, also. Code is already there for it. It’s another option to test out during daily use.

For links out of smart/clairvoyant fields, Goldenseal adds commands at the bottom of the popup menus. TurtleSoft Pro has a right-click menu instead. It’s easier to program, and easier to use.

Right-clicks are one more useful tool. I’m sure we will add more of them during testing. They are yet another way to get there from here.

Dennis Kolva
Programming Director
TurtleSoft.com

Colors, Fonts and Dialogs (Feb 25)

This week, our staff worked on the Layouts interface in our new estimating & accounting software.

Choose Custom Layouts from the Options menu in Goldenseal, and you’ll see the older version. It opens a drawing environment where you can move fields around, add new ones, and fiddle with sizes, colors and other properties. Custom Layouts is how you change the appearance of data entry screens, reports or printed forms.

Click the icon next to the paint bucket or pen, and you’ll see a pop-up palette with 256 colors. It’s how you set the fill and border color for any field. Our staff wrote that interface entirely from scratch in 1997. There’s about 150 lines of code that lays out a grid, fetches colors from a color look-up table (clut), fills them into the squares, pops a window and responds to clicks.

For text colors, you click on a text field, then choose Color from the Text menu. It shows the same color palette.

Having 256 color choices was common when we first released Goldenseal. The results fit into 1 byte. Most apps used the System palette, with evenly spaced colors (most of them very bright). We replaced it with a custom palette that has extra pastels (for backgrounds) and dark colors (for field borders and text). It’s more business-friendly. Still plenty of bright colors if you want them.

Choose Background Color from the Options menu, and you’ll see a System color picker. That’s for the newer style of colors, with millions of choices. Those take 4 bytes of storage (one byte each for red, green, blue and transparency).

We added new color pickers to TurtleSoft Pro this week. It only took a few lines of code. They show a QColorDialog, which can be either the System color picker, or Qt’s own version (similar to the one in Microsoft Excel). We’ll add a checkbox in Preferences so you can use either.

I don’t think any of the modern color pickers are quite as good as the original Goldenseal palette. For business forms, 256 colors is plenty. It’s hard to see the differences as it is. Having more choices just makes it more complicated.

However, modern systems don’t provide 1-byte palettes. It’s too much work to write another 256-color chooser from scratch. Setting colors is only a minor part of our software. So we will go with the flow and use QColorDialog and 4-byte colors.

For text formats, Goldenseal currently has a bunch of Text menu commands. It often takes several trips to the menu, and the list of fonts has grown absurdly long. We just added a Text Format button in TurtleSoft Pro that is much better. It uses QFontDialog, which also can show either a System or Qt font picker. Both have their advantages, so we’ll add a checkbox in Preferences for that, too.

The new Layouts panel is already looking pretty decent. We definitely will include it in the first release. Our staff can tweak stock layouts with it, and users can modify their own. Version 1.0 probably will skip some of the more complex features. Almost nobody uses them, and it’s not worth the delay to finish them now. If you want to modify report tables, it’s something to look forward to in a later update.

At this point, most of the unfinished work is dialogs. Goldenseal includes 119 different windows and dialogs, originally set up in CodeWarrior. Some are already replaced, and some are obsolete. But, at least half still need to be redone. Some are in Layouts: we sure could use them now to help with debugging. The rest are mostly for estimating and accounting tasks.

Like every platform, Qt has a drawing window to set up windows and dialogs. It looks a lot like our Custom Layouts. Like every platform, Qt also has a coding style to make dialogs function. Like every platform, the whole system has its oddities, gotchas and quirks. It ends up being a lot of steps.

I think it will be most efficient if we replace all the remaining dialogs and windows at the same time. Our staff will be in dialog setup mode for a while.

Dennis Kolva
Programming Director
TurtleSoft.com

OOP (Dec 1)

The Goldenseal accounting & estimating software is written in the C++ programming language. It’s about 1000 files, organized with OOP: Object-Oriented Programming. OOP is by far the best way to create large, complicated apps. It uses classes to make code seem more like the real world.

For example, for material purchases, our accounting software has a CMaterialPurchase class. It stores all the data for purchases. The class also has functional code: to calculate sales tax, post job costs, and handle accounts payable, time & materials billing and price updating.

When you open a screen to work with purchases, the CMaterialPurchaseViewer class makes the fields and buttons work properly. Every other data entry window has a similar pair of classes: one to store the data and business logic, and one for screen appearance.

Classes usually have parents. For purchases, it’s a CExpenseTransaction, which also includes subcontractor and other costs. That inherits from CBreakdownTransaction, used for everything with a breakdown table. Its parent is a CTransaction, for all types of business transactions. There are a few more layers above that.

We started programming Goldenseal in the early 90s. Back then, C++ was just starting to become popular, and OOP was a recent invention. GUI frameworks existed, but they were immature. Our programmers had to design many things from scratch.

Sometimes we made things too complicated, with too many classes. That was definitely the case for the eight action commands: Reconcile, Pay Bills, Deposit Funds, Project Billing, Sales Billing, Rental Billing, Write Payroll and Job Costs.

We just finished rewriting the last of those. One reason it went slowly is because everything needed a huge amount of refactoring. Project Billing was the hardest. It slimmed down from 24 classes to 5. Write Payroll was also difficult. It dropped from 16 to 5. Job Costing pared down from 11 to 5. The others went from 8 to 5. It also was a chance to redesign and improve a few things.

Refactoring is quite a process. Sometimes we copy code and paste it elsewhere, then tweak and rewrite until it works again. Sometimes we delete obsolete code, then clean up the mess left behind. Sometimes we rename things, just to see how they work. Along the way we try to figure out the quirks.

Goldenseal has all sorts of weird code for retainage, money paid on account, different types of change orders, salaries vs hourly, yada yada. Running a business is complicated. All those business eccentricities seep into the interface, and it takes effort to move them to a new framework.

Most likely we missed some things, or messed up code that we didn’t understand. The same applies for everything else that our staff has done in the past 15 months. The good news is that we have finished at least a first pass through all parts of Goldenseal. Everything is doable, even if it’s not perfect yet.

So, it’s finally time to move on to the next phase for TurtleSoft Pro. Testing, and retesting, and fixing everything that isn’t right. I’m sure it will take all winter.

At least we have a well-tested app to compare it with. We don’t have to think through all that logic again, or fix 20 years of bug reports from users. We just need to make TurtleSoft Pro act the same as Goldenseal.

Dennis Kolva
Programming Director
TurtleSoft.com

Change Order Billing & Debugging (May 13)

A long-time user of our accounting software called in recently with a problem in their change order billing. There was a mystery retainage amount that showed up when they billed for the project.

It turned out to be a bug in the printed form. Goldenseal does not track retainage on change orders, but it’s on the printed bill layout. The amount comes from the main project: that works fine for regular project billing, but it is just confusing for change orders. The solution is to use Custom Layouts, and remove that field from the form. Here are instructions to remove it.

This bug has been around for almost 20 years. It’s only a problem for users who create change orders, and also do projects with retainage. Otherwise it just shows zero. That may be why nobody has reported it until now.

For some reason, Change Orders have always been difficult.

Our C++ source code uses object-oriented programming (OOP). Everything is an object, usually inheriting code from parent objects. Allowances, Change Orders, Sales and Rental Transactions all generate income, so they have the same parent. The problem is that some people want change orders to act like miniature projects. Those are job accounts, which have very different parents. There’s no good place to put code that both can use.

For a while, we addressed user requests by duplicating Project code into Change Orders. It became more and more difficult. We finally backed off and decided that Change Orders just need to be their own thing. If you withhold retainage on one, it’s complicated enough to be a separate project. Likewise, if you want a detailed change estimate, create an Estimate record. Those have fancier breakdowns that handle all sorts of estimating quirks. You can link the Change Order to it.

There are some deeper reasons for the bug.

Our estimating and accounting software started out as simple spreadsheets created to run Turtle Creek Carpentry. It was a small remodeling company that didn’t need much paperwork. After computerizing, we took on bigger projects that sometimes involved change orders, retainage, and other fancy stuff. But that only lasted a couple years before the software business took over from construction contracting.

Many of the features in Goldenseal come from user requests, rather than our own needs. Sometimes the programmers must guess how the code should be set up. Sometimes the guesses are wrong. Most programmers do not have in-depth knowledge of estimating, accounting or whatever. There’s a certain amount of faking involved.

We listen to tech calls and user feedback, then fix the bugs to get everything working properly in the next update. It’s something that every software company must do.

Even worse, there is a huge range of construction business types and sizes. They all have different needs. When we add new features, it’s important to not make things more confusing for the users who don’t need them. That takes some judgement and design skill. Sometimes we need to back-track or remove features that are too confusing.

Meanwhile, the past couple months I’ve been wrapped up in real estate selling and buying. It has been interesting, but it’s winding down. More details in the next post.

Dennis Kolva
Programming Director
TurtleSoft.com

File Formats (Apr 23)

Back in 1994 I made detailed blueprints for my current house: enough to get a building permit for the rehab work. Now that it’s for sale, I wanted to show the plans as a selling aid. All the construction project files were still there in an old backup, but nothing would open the drawings.

I don’t even remember which app created the plans. Maybe MacDraw II, maybe MiniCAD. Definitely nothing that runs on current Macs. There is still one laptop here from the early 2000s, but nothing on it would open the files. All the older hardware died years ago.

As developers, Turtlesoft has had a hard time keeping up with changes on the Macintosh. It’s also a problem for plain old users. When an app dies, so does all the data that it knows how to unlock.

I’ve tried out a few simple CAD programs to whip out plans, both for the current house and the probable next one. FloorDesign2 seems like the best so far. However, it uses its own file format. You can print and then save as pdf, but the details won’t transfer to any other CAD apps.

Some types of data do have universal formats. For text, there is plain text (.txt) and rich text (.rtf), which many apps can read. Spreadsheet data translates well as either tabbed text, or comma separated values (.csv). Page layouts can use either .pdf or .html. Databases often uses SQL.

In addition, some apps are so dominant that other software is forced to support their file format. Excel and MS Word are that way. QuickBooks aspires to that role, at least for add-ons. AutoCAD may do it for higher-end CAD. Unfortunately, many apps have their own unique data formats, and it’s difficult or impossible to move it elsewhere.

I don’t know if there is any good solution for this, except for keeping old computers around. They seem to last longer if used regularly.

These struggles also apply to our Goldenseal software. You can export any data to a text file and then open it in Excel. However, there’s no easy way to move all the accounting details to some other app in a single step.

The transfer problem works both ways. We wrote code to import from QuickBooks, but it can only translate some of the data from their export file. The translator brings in all the account setup details, but not purchases, bank transactions or job costing. The two formats are too different. Importing from any other accounting software would be even harder.

One issue for accounting software like ours is security. Having the file format be too accessible is not a good idea. Too much risk that data will be changed or stolen. The Goldenseal file format is not encrypted, but viewing the raw file data is not very useful. Even if someone clever had access to your computer, it would take many hours for them to figure out how to, say, find and change a paycheck amount.

If you are really worried about that risk, you can encrypt the whole hard drive, and protect everything on it. All of the fraud problems we’ve heard about from users have come from employees who could just sign on and enter stuff the usual way. Preventing that kind of fraud requires careful use of password access, and occasional audits by the owner or their accountant.

An employee who enters data should not also be reconciling bank statements. Having a second set of eyeballs on the money adds a ton of security.

Dennis Kolva
Programming Director
TurtleSoft.com

Goldenseal Pro

The bad news is that the Kickstarter did not reach its goal. There were 23 backers and $7000 pledged.

The good news is that bids for the programming work came in lower than expected. Two freelancers from Sweden & India respectively, have already done Carbon to Cocoa conversions, and seemed very competent from our message exchange.

So, we are now accepting pre-orders for Goldenseal Pro, and the project can probably still proceed on the original schedule.

If you have questions, please contact us by email or phone (607 220-4514).

Thanks,

Dennis Kolva
Programming Director
Turtle Creek Software

Goldenseal Access from Anywhere #2

These days, almost everyone carries some sort of mobile device. The big question is, how do you connect it to your business computer(s) when away from the office?

Questions 2 to 4 from yesterday are: where is the application located? What runs the user interface? And, how do the devices communicate? I’ll try to cover them all at once. This will get pretty technical, and if you want the short answer, you might better just skip to the end!

APP DEVELOPMENT ABCs

We consumer software developers have three basic choices. We can create desktop apps that run on Mac, Windows or Linux. We can write mobile apps for iOS or Android. Or we can build a web app, which runs inside a browser.

Desktop and mobile apps run code on the local machine. Apple pushes Objective-C (and soon, Swift) as a programming language for both Macs & iOS (iPhone, iPad). Android pushes Java. However, C++ (the language we use for Goldenseal) is popular and very solid, and all platforms support it. It gives excellent performance with high reliability (if you use it right!), and is probably what is used most often for “serious” software.

Web apps are probably the hottest thing to program, these days. They need a “back end” server app running on the website hosting machine– most often written in PHP with a MySQL database, but there are many other choices. For interface, they may also use a “front end” app that loads along with the web page html, usually written in Java or JavaScript, with many other choices.

WHERE WE ARE HEADED

I spent a few months last winter, learning new languages and considering a switch to web app development. Unfortunately, http and web protocols were designed primarily as a page-rendering system, not for secure business use. Many programmers are valiantly making banking & e-commerce work on the web, but it’s an ugly process, and there are many ways to fail badly. Languages and standards are also rapidly evolving, so code has about a 5 year lifetime before it needs a total rewrite. Maybe web development will be mature in 10 years, but right now it’s a tough environment.

On the other hand, desktop apps are stodgy but stable. Yes, Apple has gone through 3 OS designs, 4 basic languages, 3 hardware chips and 3 development platforms since we first prototyped Goldenseal, but that is still a much slower pace than the current WWWeb. Our 14-year-old Goldenseal code still runs OK, and it doesn’t need a ton of work to last another 14 years. In general, we have well-tested, stable, reliable code that would be nice to keep using.

A few Goldenseal users already have managed to connect remote laptops to their offices via a VPN (Virtual Private Network). VPN a feature built into all modern desktop and mobile devices, which lets you use the Internet to hook into a wireless or Ethernet network. However, it’s not very easy to set up, and we currently use a server-discovery process (broadcast UDP) that is blocked by many VPN routers.

CONCLUSION

VPN seems like the way to go, and we can rework the network code in Goldenseal Pro, to make it easier to connect.

For laptops, that would mean signing on to your office server, from anywhere that has a decent Internet connection. It would look exactly the same as if you were in the office, with acceptable speed.

For phones and pads, we can write new mobile apps that would let you do the same thing– but it will need a much simpler interface, designed for small screens. It may work best to have separate small apps with just one function: enter an expense, view an estimate, enter a customer contact. Android & iOS are really not well-suited for complex business apps.

We have been playing with designs for an on-site pocket estimator, using inteface that we first developed for BidMagic and its precursors. Estimating will work better on pads than phones, since it is really tough to do much on a screen with only 6 square inches.

Comments appreciated!

Dennis Kolva
Programming Director
Turtle Creek Software

Goldenseal Access from Anywhere

We just received this question by email, in response to the announcement for Goldenseal Pro:

Hi this is fascinating. But are you ever going to build something that can be web hosted? I need a solution that I can use at two locations- working on files with my business partner. –Pierre

I think it’s fair to say that almost all of our users want something similar. We need something similar ourselves, to run our increasingly mobile software business! However it’s a complicated topic, and probably should be split into 4 smaller questions:

Where is the data stored?
Where is the application that accesses it?
What runs the user interface?
How do the different devices communicate?

I’ll answer #1 now, and need to think a bit, for good answers for the others.

Our current model is to store your company data on your own, local hard drive. It’s secure, convenient, and can be automatically backed up by the OS (Mac: Time Machine, Win: Control Panel -> Backup and Restore). You can put a copy on your laptop, and access your data even where there is no phone or Internet connection. Files are not very big, so it’s not a burden to store them.

Quickbooks Online offers a web interface and convenient storage of your data on their servers. That approach is great for Intuit, since they kind of hold your data hostage. It locks you into their service, and gives them a regular monthly income pretty much forever. We have definitely considered doing something similar.

However, quite frankly, we don’t have the balls to go that route. It would require a lot of web programming and interface compromises, and there are many, many security issues that we surely would not get completely right. Web security is extremely hard. Some day, Intuit will probably have a huge hacker breach and/or loss of many people’s data, but they are big enough to survive it. We’re too small to take on that kind of risk and responsibility.

So, we will probably stick with our current model of local data storage. Since most users do not host a website from a local computer, we can’t get that data into an http/website stream easily. However, we already have multi-user code to share data on a local network, and just need to improve our VPN (Virtual Private Network) interface so you can connect securely over the Internet.

That’s one of many things we can do better after we get out of our old PowerPlant/Carbon/QuickTime code, and into modern frameworks.

Dennis Kolva

Programming Director

Turtle Creek Software