Month: April 2012

Change is inevitable

on April 27, 2012

As we get close to the beta version of HDXPRT 2012, I wanted to let you know how it compares with the original design specification. As inevitably happens in any software project, there are differences between the original design and the final product. Generally, things have stayed pretty close with HDXPRT 2012, but there are two changes worth noting.

First, in the design specification, we specified Audacity 1.3.14 Beta in the Music Maker scenario as that was the only version that supported Windows 7 at the time. Audacity 2.0 with Windows 7 debuted in the interim so we are using that version.

The second and more significant issue was with Picasa, which was to be part of the Media Organizer scenario. Unfortunately, we couldn’t create a stable script because scripting tools like AutoIT could not properly recognize some of Picasa’s application UI elements. Somewhat reluctantly, we ended up replacing Picasa with Photoshop Elements. We still think the scenario is a good one and Photoshop Elements is an appropriate tool. I would have liked, however, to have Picasa in there.

There are probably some more minor differences between the beta and the design specification. We’ll let you know what they are when we have the beta ready in a couple weeks. (Hopefully!) We’re looking forward to getting that into your hands and getting your feedback. If you’re not already a member of the Development Community, I encourage you to join so that you can get your copy of the beta when it is available.

Bill

Comment on this post in the forums

HDXPRT 2012 – Testing the test

By Bill Catchings

on April 20, 2012

We’re currently starting testing on alpha versions of HDXPRT 2012. In order to do that, we’re putting together a testbed. We have two goals for the testbed that are somewhat contradictory. The first is to make the testbed as diverse as possible in terms of vendors and configurations. We want notebooks and desktops from as many vendors as possible. We want to make sure we have systems that will push the edges—both slower systems that may even be below the minimum recommended configuration and faster ones representing the current latest and greatest. These systems will help us shake out bugs and provide some raw data that we can publish when the benchmark debuts in the new results database.

The second goal for the testbed is to have systems where we can easily change one variable at a time to help us understand the characteristics of the benchmark. Typically, these are white box systems where we can swap processors, disks, RAM, and so on. We will use the results from these systems in the benchmark characterization white paper we will create for the debut of HDXPRT 2012.

We’d like your opinions on what we should be certain to test. We think we have a good handle on what to include, but we want your ideas as well.

We also are looking for additional systems to include in our testbed. If you can supply some, please let me know. That is one way to make sure HDXPRT 2012 works on your system and to get your results in the results database. Rest assured, we will not publish those results without your permission. Regardless, the more systems we can test, the better the final product will be.

There will, of course, be opportunities for you to help with the testing as we get to the beta stage in the near future.

Bill

Comment on this post in the forums

Posted in HDXPRT 2012, HDXPRT development process, Let us know your thoughts |

Touch: The finger versus the stylus

By Bill Catchings

on April 13, 2012

One advantage of being in the industry for a long time is seeing the development pendulum go back and forth. One such pendulum is the way of interacting with touch interfaces. Touch interfaces existed long before the current phone and tablet devices. I remember the HP-150, an early touchscreen PC, from my days working on Kermit in the 1980s. It was not a big seller, so you probably never used one. However, you may have used early touchscreen technology in devices like kiosks. While those touch interfaces were fairly simple, you used your fingertip on the screen to indicate your selections.

When PDAs became a big deal in the 1990s, the stylus rather than the fingertip became the way to touch the screen. If you lost your stylus or did not feel like pulling it out of the case, you could use your fingernail. I became very good at writing in the odd script that the Palm OS used. (I still sometimes write the letter A as an upside-down V.) Though the stylus was easier, you could do most things using your fingernail. I also used a stylus (and my fingernail) with Windows smartphones.

Smartphones, especially the iPhone, swung the pendulum back to touching the screen with your fingertip. It took me a decent bit of time to adjust to touching the screen that way. I also had to get used to staring at screens through fingerprints. The ability to multi-touch, however, made that worthwhile. (And, caused me to make sure I always carry those screen-cleaning cloths.)

Recent tablets have generally utilized multi-touch, fingertip interfaces. I still find myself wishing for a stylus at times. I’ve purchased a few different styli for using my iPad, but the mushy, fingertip-like ends leave much to be desired. I just ordered an interesting compromise, the Adonit Jot Classic Stylus. I’m hopeful, but won’t be surprised if I’m disappointed.

The stylus on some Windows 7 tablets like the Dell Latitude ST shows what is possible with a stylus. The stylus can be really useful in some work environments. Hopefully, we’ll see more innovation in touch interfaces. In my ideal world, I could use a simple stylus or my fingernail some of the time and my fingertips when multi-touch is better—all on a single device, of course! For now, I just have to keep cleaning off my iPad’s screen while I try to find the ideal stylus.

Whatever way the touch interface pendulum swings, we’ll try to make sure that TouchXPRT will be the right tool to measure it.

Bill

Comment on this post in the forums

Posted in Touch-based devices, TouchXPRT |

Back to the future of source code

By Bill Catchings

on April 6, 2012

Today I’m spending a good chunk of the day participating in a panel discussion on the Kermit file transfer protocol as part of an oral history project with the Computer History Museum. A little over 30 years ago, I worked at Columbia University on the original versions of Kermit. In preparing for the panel discussions, I’ve been thinking about projects with available source code, like Kermit and HDXPRT.

Kermit was a protocol and set of programs for moving files before the Internet. We designed Kermit to work between a wide variety of computers—from IBM mainframes to DEC minicomputers to CP/M microcomputers. As such, we wrote the code to accommodate the lowest common denominator and assume as little as possible. That meant we could not assume that the computers all used ASCII characters (IBM mainframes used EBCDIC), that 8-bit characters would transmit over a phone line, or that packets of more than 100 characters were possible (DEC-20 computers specifically had an issue with that). The pair of Kermit programs negotiated what was possible at the beginning of a session and were able to work, often in situations where nothing else would.

We developed Kermit before the open-source movement or Gnu. We just had the simple notion that the more people who had access to Kermit, the better. Because we did not want incompatible versions of Kermit or the code to be used for the wrong purposes, we retained control (via copyright) while allowing others to use the code to create their own versions. We also encouraged them to share their code back with us so that we could then share it with others. In this way, Kermit grew to support all sorts of computers, in just about every corner of the planet as well as outer space.

In many ways, what we are doing with HDXPRT and its source code is similar. We are working to create a community of interested people who will work together to improve the product. Our hope is that by having the HDXPRT source code available to the Development Community, it will encourage openness, foster collaboration, and spark innovation.

I believe that what made Kermit successful was not so much the design as it was the community. I’m hoping that through the Development Community here, we can make just as successful HDXPRT, TouchXPRT, and who knows what else in the future. If you have not already joined, please do—the more folks we have, the better the community and its resulting benchmarks will be. Thanks!

Bill

Comment on this post in the forums

Posted in HDXPRT Development Community benefits, HDXPRT source code, History of computers, TouchXPRT |

Month: April 2012

Change is inevitable

HDXPRT 2012 – Testing the test

Touch: The finger versus the stylus

Back to the future of source code

Check out the other XPRTs: