Planting Schedule in Table Form

Amy,

Since it was my design decision to make it that way, I feel like I should at least explain my reasoning.

First though, if we are talking about awkwardness of design, I personally feel the non-plot gridlines is a substantially more attractive schedule. I just don't think there is a need for the visible gridlines, but, I do freely admit that is personal preference, and I fully appreciate it matches more with schedules in Revit and imported Excel spreadsheets, so I get why some prefer the look of the visual gridlines. (As an aside, luckily in the Concept Schedule, its design absolutely does not work with visible gridlines, so we were lucky to be able to just have a single look of the schedule, which does dramatically reduce the time required to develop and maintain it.)

For the symbols, in the example you can see that the hatches absolutely need to fill the entire cell. In the attached mockup with it otherwise, it becomes instantly far too busy, and just looks like an error. It is also just needlessly leaving less room for visual identification of the hatch. Once the size of the cell is set, it is clear that the hatch should just fill the entire area for maximum readability of the pattern, and also helpful determination of the extents of the row -- note this is also very important when including Concept plants by Group, as one must see the extent of the hatch to appreciate the palette of plants that it applies to.

So then once the hatches are that way, I feel the exact same logic applies to the tree and shrub blocks. There is just nothing to be gained in my mind by needlessly reducing the size of the symbols. The larger the symbol, the more readable it is, and the less need to display symbols at plan size, further increasing the size of the schedule. So again, I feel it just merits the exact same logic as the hatches, that once the row size has been determined, the overriding need is for the symbol to be as absolutely as large as will fit within the cell, for maximum identification. And then this aligns with the hatches, as they are both following the same design rules.

But, as I first said, I still do feel the gridlines non-plot option is a superior look, where in which case the blank space between the symbols is used as the visual distinguishing factor to differentiate them. It works extremely well there, and is a very clean looking schedule while also being incredibly readable.

And last, as for the header alignment - it is actually not bottom aligned, but purposely has a blank space above the header. This is to help with the visual sight lines, to make clear that it is a break from the section above, but using the smallest amount of space to do so. As such, it accomplishes this within a single table row, where if it were to use two table rows to accomplish this, it would look very odd. With the header simply centered within the row, I felt it did not look enough like a break from the section above, that the blank space should be above it. But also from a technical perspective, it works better to accomplish the header via additional linebreaks within the cell. For instance, if a header title needed to wrap to a second line, and the row had a fixed height and was aligned center, then the two lines of header text would completely fill the cell, making it hard to read. So instead, there is a linebreak before the header, pushing it down, and accomplishing the row height exclusively through the linebreak and the header text. And once accomplishing the header row sizing in this manner, the dilemma becomes, should it be "linebreak Header linebreak" or "linebreak Header". And here again, I felt the best was the smallest possible vertical space, always trying for the schedule design that has the least vertical space. So here we went with the single blank line above the header, in a single row, as the best way to convey a section break in the least amount of space.

But overall, we want user feedback with the new schedule. This is why we had a webinar back in September with the new schedule, and the ability for users to try it out ahead of time and give us their thoughts. We absolutely need to be able to communicate new features to users, and our best tool for that is the Newsletter and our Webinars. I absolutely beseech you and all users to please be sure to subscribe to the newsletter, and attend the webinars on relevant subjects. The time to have these sort of design discussions back and forth is *before* a feature is released. We will be making several changes to our Update system, our Webinar schedule, and our Newsletter for next year to specifically address this, and solicit more user interaction on new features before they are released.

--J