Saturday, September 7, 2019

A C++ Hall of Fame

Rock & roll has a hall of fame. So do toys. Fresh water fishing and towing each have one, and there's one for pretty much every kind of sport. I think C++ should have one, too.

CppCon, which starts in about a week, provides a natural setting for discussions about a C++ Hall of Fame. To get things rolling, I present the following proposal, on which I welcome comments. I won't be at CppCon, but I'll send a final version of the proposal to The C++ Foundation before the conference begins. Let me know what you think! (If there are a lot of comments, don't be surprised if I don't respond to each one.)

Proposal for a C++ Hall of Fame ("HoF")

Motivation

The success of C++ is based on the efforts of many contributors, but a few have done especially significant work. A C++ HoF would allow the C++ community to formally recognize and honor contributors whose efforts have been unusually important.

Administration

The HoF will be run by a Steering Committee, whose size and makeup will be determined by the Standard C++ Foundation. Duties of the Steering Committee will include overseeing the nomination, selection, and induction of HoF members, as well as maintaining the HoF itself.

The Steering Committee will establish a Selection Committee, whose role will be to solicit, accept, and evaluate nominations for HoF membership. The Selection Committee will determine who is included in the HoF.

Membership in the Steering and Selection committees need not be disjoint. Membership may even be the same, but it may be preferable for some Steering Committee members to work only on HoF activities unrelated to nomination or selection of new HoF members.

Eligibility for HoF Membership

HoF eligibility will be determined by the Steering Committee.  I suggest that, initially, only people (living or dead) or teams (i.e., groups of collaborating people) are eligible for membership in the HoF. In the future, eligibility can be broadened (e.g., to permit companies and organizations), but I think it’s reasonable to begin with a people-only HoF.

To reduce conflicts of interest, no one involved in HoF administration is eligible to be selected for membership in the HoF. However, existing HoF members may serve as administrators, and former administrators are eligible for the HoF.

Nomination

The nomination process will be determined by the Selection Committee.  I suggest an initial “anybody can nominate anybody” policy and a generous nomination period. If this proves unwieldy, more restrictive policies can be adopted.

Selection

Each year, the Selection Committee will choose no more than five nominees for inclusion in the HoF. Selection is an honor. Choosing too many new members would dilute the effect.

The primary criterion for selection is that the nominee has made one or more unusually significant contributions to the success of C++. Such contributions may have been made in the areas of design, specification, implementation, application, explanation, popularization, or any other aspect of C++ that the Selection Committee deems appropriate.

The Selection Committee may consider negative factors outside the realm of C++ when determining whether a nominee is worthy of HoF membership. If a nominee is guilty of a heinous crime, for example, the Selection Committee may take that into account when deciding whether to select the nominee for the HoF.

Inductions

The Steering Committee will determine how inductions are to take place. I suggest that CppCon schedule an induction ceremony as part of its program, during which new inductees are awarded a membership token (e.g., certificate, trophy, gaudy ring) and given time to make public comments marking the occasion.

The first group of HoF members will be selected before CppCon 2020. This will make it possible for them to participate in an induction ceremony during the conference.

Manifestation

The Steering Committee will determine what form the HoF will take. I suggest beginning with a HoF web site (cpphof.org?) that showcases each member and summarizes the contributions that led to their inclusion.

Saturday, January 19, 2019

Adventures in UX disasters: The Pioneer AVH-2440NEX dimmer control

To provide a display for the backup camera I recently had installed on my car, I had a Pioneer AVH-2440NEX head unit installed in my dashboard. The display was distractingly bright at night, so I set out to dim it. The unit supports automatic night dimming, so I figured this would be easy. It is, but only after you've endured a UX hazing ritual of the kind that's distressingly common in the software industry.

On the AVH-2440NEX (and related models), there is a display setting called Brightness. It does not control the brightness of the display. It controls the blackness of the display. The brightness is controlled by the Dimmer setting. Dimmer has a range of 48 values, 1 to 48. Larger Dimmer settings decrease the dimness of the display, because Dimmer controls the display's brightness.

Values for Brightness (which do not control the display's brightness) are -24 to 24.

To summarize: The display brightness is controlled by a setting called Dimmer, which has a range of 48 values starting at 1, with higher values decreasing the dimness. The display blackness, in contrast, is controlled by a setting called Brightness, which has a range of 49 values that start at -24.

Sigh. 

Think of all the professional developers--UX designers, programmers, QA people, managers--who had to sign off on this before it shipped to customers. I don't understand how they could collectively believe that this is a reasonable (much less intuitive) design for mainstream consumers.

Scott