The focus of this blog is construction-related topics. The purpose is discussion, so please feel free to comment! See Specific thoughts for thoughts from the daily life of a specifier.

06 December 2017

Wayward websites

There's often a lag between the time something new comes along and the time it is fully incorporated into our lives or work. When websites first came online, in the mid-'90s, they had obvious potential but companies weren't sure what to do with them. As I recall, many of them focused on the history of the company, stocks and market activity, and various other things useless to most visitors. The content was what the company owner thought was interesting; it was not what the prospective customers needed.

At the time, there wasn't much in the way of instruction for web designers and there were few rules about how to make a website work or what it should be. An architecture firm in my area had a beautiful website, graced by one the firm's most impressive projects. The problem was, it took forever to load. I analyzed the code and the files, and discovered they were using a huge image file. They apparently didn't know that there usually is no discernible difference between an image file of a few kilobytes and the same image in a two-megabyte file.

Eventually, website designers grew familiar with HTML and the way web pages should be formatted, companies learned what users wanted, and users learned how to search websites to find what they wanted. Even though most websites weren't perfect and many had serious problems, websites became much better and continued to evolve.

And then, along came mobile devices. At first there were few problems, but in typical fashion, the more people used their smartphones, the more they expected from them, and the more they became like miniature computers, able to do most of what their larger cousins were able to do. Unfortunately, their size - the very thing that made them so useful and contributed to their rapid growth - limited the amount of information they displayed. Monitors had been growing in size for many years, and software was written to take advantage of the available space. Despite the obvious limitations of a small screen, users demanded that websites be fully functional on a smart phone, and website designers did what they could to make everything available to this new market.

All that makes sense, but instead of making everything work, computer and software designers merely moved the problem from one machine to another. The first image in this article is a screen capture from my iPhone. It's close to actual size, so you can imagine that it isn't easy to work with. The picture can be resized, though, making it easy to access the various options. The same image on my desk monitor fills the screen from top to bottom. All of the twenty-one links to other information are large enough to read, and all are visible at the same time.

I've been using multiple monitors for a few years, and I've found that I have not yet reached the point where I have enough of them. I used two (the notebook monitor plus one external monitor) for a few years, and acquired a third this summer. It's so much easier to work when several documents or programs can be displayed at once, rather than having to continually pull one on top of the others!

The result of these changing technologies is that I finally have about as much monitor area as I want, but because of the drive toward miniaturization, that space is poorly used by today's software. Here's a picture of my monitors:

Both are 24-inch monitors, with a viewing area 20-1/2 inches wide by 16 inches tall. That's 164 square inches, or 1.14 square feet per monitor. Total: 2.28 square feet. My iPhone has a screen that is 2-1/2 inches wide by 4 inches tall, total area 10 square inches, or 0.07 square feet.

Now look at the websites on my monitors. Notice the inefficient use of more than two square feet to show two nearly full-screen images and a handful of words. That may work on my iPhone, assuming I wanted to try to use it to read large quantities of information, but it makes no sense on a standard monitor.

You might be inclined to dismiss this problem, knowing that it's easy to scroll down or choose a menu option. That would be fine, but the same format typically is used throughout the website. So, instead of being able to read a reasonable amount of text on that big monitor, the user is forced to scroll through huge graphics and choose options presented in oversized icons. Here are two more examples that show how something designed for a tiny screen makes no sense on a monitor.

I can easily display two Word files on a single screen with a font size even I can read without my glasses, a total of about 1,000 words. With websites like those illustrated here, I might see as only much as 100 words plus a few icons on the entire screen!

Other irritating features of many sites are the pop-up and drop-down screens that often conceal much of the information that was present. Some of these suddenly appear or disappear as the cursor is moved, while others hang on until the cursor is moved to another place.

The crazy thing is that many of these probably are award-winning websites. They can be beautiful, and the bells and whistles can be interesting, but instead of helping the user, they present more obstacles to finding useful information. In a way, they're like magazine architecture. Lots of wow factor, with function as an afterthought.

There are ways that websites can detect what device you're using and modify the website content to fit. In fact, the Clarus and Deko websites use this technology. If you visit those sites, you'll see that the arrangement and size of the things you see will change as you shrink or expand the browser window. Unfortunately, the font size appears to be fixed, and while some images will change size, there seems to be a lower limit, and the sizes of many icons are fixed. So, despite the flexibility, the information density is high only on mobile devices, and what is seen on a large monitor is mostly empty space.

For an interesting discussion of current website layout, see http://blog.teamtreehouse.com/which-page-layout.

What has your experience been? Do you find yourself doing a lot more scrolling and searching now? How often do you look for product information with a smartphone instead of a computer? Do you write or read specifications on a smartphone?

07 November 2017

Is it time for change?

Design-Build Institute of America
When I became a specifier in 1985, all of the projects I worked on used the "traditional" design-bid-build (DBB) delivery method. And ten years later, when I started my current job at BWBR, all we used was DBB. That shouldn't be a surprise because, at the time, there was nothing else, at least in the building construction industry.

The Design-Build Institute of America (DBIA) was founded in 1993, coincidentally the same year that USGBC appeared. At the time, DBIA made what seemed to be optimistic projections of a future dominated by design-build (DB), with a corresponding decrease in design-bid-build. That prediction is nearing fulfillment, though perhaps at a slower rate than first expected.

Despite the growing popularity of DB, my office has been involved in only a few of these projects. Even so, we rarely do DBB projects. Instead, we now use almost entirely one of the CM (construction manager) delivery methods.

As we moved away from design-bid-build projects, we changed our specifications accordingly. During this period I noticed a number of changes in the way we did our work. In 1996, we completed design, issued bidding documents, and typically issued only one or two small addenda, often none. Today, in contrast, we break projects into at least two bid packs, issue documents before they are done, issue at least two large addenda, and finish design using shop drawing submittals.

To accommodate these changes, AIA, EJCDC, CSI, and other organizations have been creating new documents and procedures, and, more importantly, contractors and design professionals have been modifying their processes, though in a less coordinated way. The result is less than satisfactory.

In a nutshell, we're using documents and procedures that were written decades ago, designed specifically for DBB. Any other delivery method requires that we use our standard documents in at least slightly different ways, ignore some of them, and often force them to do something they weren't designed to do.

For each delivery method other than DBB, the contractor has already has some relationship with the owner, and has made at least some decisions about how to do the project. In DB and in CM agent projects, the owner and contractor have an agreement and an understanding about how the work will be done. In those cases, there is no point in specifying what has already been agreed to. Even when the CM is at risk, the CM's involvement in the project during design affects the designer's work, and it affects the contractor's work as well.

Because the contractor is already on board, the front end is altered drastically by removal of bidding requirements, and Division 01, much of which tells the contractor how the designer will run the project, can be greatly reduced.

Specifications, instead of telling the contractor what is required, frequently can simply document the decisions of the project team. For example, instead of specifying and detailing a specific waterproofing system and hoping the contractor uses something similar, the designer, contractor, and waterproofing sub get together and figure out the best way to do the waterproofing. The construction documents then document the decisions. The specifications, instead of being several pages long, can be reduced to a simple statement of which products will be used.

Scheduling also has changed. Instead of stating a single completion date for substantial completion, the contractor, owner, and designer discuss how the schedule will be determined and incorporated. Instead of issuing documents on a single document date, we respond to contractors who want documents when they need them, and that often means delivering incomplete documents so the contractor can seek subcontract bids for things that have yet to be designed. Taken to conclusion, all references to phases and bid packs can be eliminated, and the designer can issue information continually. A comprehensive document control system will ensure that everyone has access to only the current information.

The design phase and the construction document phases, then, change from pure design and specification to collaboration and documentation of what was agreed. That being the case, why do we continue to prepare construction documents for other delivery methods in the same way we do for DBB?

Perhaps it's time for the equivalent of a constitutional convention. Let's invite representatives of the traditional entities - owner, designer, and constructor - and their subcontractors, throw out all existing documents, and create new documents and procedures designed for the non-DBB delivery methods.

What do you say? Are you feeling revolutionary?

26 September 2017

The making of a convention

A lot goes into a convention: location, scheduling, publicity, solicitation of exhibitors, invitations to potential attendees, and more. Although the exhibit floor is extremely important to exhibitor and attendee alike, the educational seminars and activities are equally important.

Those activities take many forms. The traditional lecture format continues to be popular, but interactive presentations have been increasing. Panel discussions, which seem to be either dreadful or very interesting, allow audience participation. In the last few years, we have had presentations and live demonstrations on the exhibit floor. On occasion, these involve one of my favorite activities - getting your hands dirty. Another recent addition has been YP Day (young professionals day), a collection of special events aimed at young professionals and others new to the construction industry.

I've always known that choosing presentations and speakers must be difficult, and this year I learned how true that is. In December of last year, I was asked to serve on the CONSTRUCT 2017 Education Advisory Council, the group that helped selected this year's speakers and presentations. The Council was led by Jennifer Hughes, Informa Education Manager. In the past, I had made suggestions about presentations, so I felt obligated to accept the challenge.

22 August 2017

Where do bad specifications come from?

It's approaching ten years since I wrote "The Making of a Curmudgeon." In it, I reminisced about my decision to run for Institute Director and thinking, "Holy cow, when my term is done I'll be almost sixty!" Well, sixty came and went, and I recently celebrated my twentieth anniversary at my office.

Milestones like that tend to make one look back, to think about what has happened, to think about what might have been. During my thirty years as a specifier, I thought things would improve, that specifications would get better, that relations within the construction team would become more collaborative and trusting, that drawing details would gradually lose the pesky problems that lead to problems in construction, and that, eventually, the construction process would be a thing of wonder, with few difficulties. I thought that when it came time to retire, I could look back on continual progress and leave knowing that the world was a better place, due at least in some part to what I had done.

01 May 2017

Small brush with fame

Lawrence Small, son of Ben John Small, and me
One of the most treasured awards I received from CSI is the Ben John Small Memorial Award. First presented in 1996, and limited to one per year, only eleven people have received this award.

The award, originally intended "to honor those who have achieved outstanding stature and proficiency as specifiers," is named after Ben John Small, charter member and president of the Metropolitan New York Chapter. Ben was well known as an educator; he was a frequent lecturer at Columbia University, Princeton University, the Massachusetts Institute of Technology, and the Virginia Polytechnic Institute. He wrote columns for Pencil Points Magazine, which later became Progressive Architecture. He also wrote a number of books, including Architectural Practice, Building check list, and Streamlined specifications standards. (I have two of these books in my library.)

A couple of years after receiving the award, I was at the CSI office in Alexandria for an Institute board meeting. I recalled seeing an article about Ben John Small in the Construction Specifier, but all I could remember was that his son worked at the Smithsonian. I had a little extra time before my flight, so I went to the Smithsonian in hopes of meeting him.

14 March 2017

Spock as a specifier

In our never-ending search for truth in specifications, we often lose sight of reality. We're inundated with advertising, product data, test reports, and white papers; where once specifiers complained about a lack of information, we now struggle to keep up with what we receive. We can't know what we don't know, and we have no time to evaluate what we have seen. As if that weren't bad enough, we often find that what we thought we knew isn't true.

As an example, consider building insulation. The way it works and its value have been understood since antiquity, and until recently we have felt comfortable with evaluating, specifying, and detailing various types of insulation. And then everything began to unravel.

14 February 2017

Tower of Babel


"Come, let Us go down and there confuse their language, that they may not understand one another’s speech."

I recently enjoyed watching a video clip of a senate confirmation hearing, in which Scott Pruit, EPA Administrator nominee, was being grilled by Joni Ernst, Senator from Iowa. At issue was the term WOTUS, or "Waters of the United States." Not knowing at the time I watched it what the term meant, it was amusing to see that 97 percent of Iowa would be governed by expansion of the existing definition. Further discussion focused on puddles and on a definition of a parking lot puddle as a "degraded wetland."

The labyrinthine regulations of the federal government reminded me of regulations we in construction deal with every day. They are similarly complex and obscure, differing only in extent. I was not surprised that I didn't understand the subjects of the senate hearing, but on further thought, I realized I really don't know much about the countless codes and regulations that govern construction. Nor, I'm sure, does anyone else.