Archive for March, 2011

Blogging Loves Me, It Loves Me Not…Or Vice Versa

I have a love-hate relationship with blogging.

There are times I have a few extra minutes, I really, really want to blog something, and….nothing. I can’t think of a single thing to say.

And then there are times like today when dozens of thoughts race through my head. I try to make notes for later — must blog about this, and that, and the other. And then when it comes time to write about it? Um, yeah…I forget what I really wanted to say.

Blogging feels a little arrogant and egotistical, like…I have so many important thoughts, I write them in a blog. It also can feel contrived. Trying to come up with something pithy or interesting enough or new to say on a subject. And self-censoring to not offend the sensibilities of…whomever.

Despite all of that…I blog. And I love it. And somehow, through the self-censoring and everything else, it’s still me that comes through. Quirky, geeky, passionate about certain issues, some guy like…me.

So I won’t blog today about the thoughts that were racing through my head. No time for that. 🙂 But I will try harder to remember what it is that I *wanted* to say, and get back to saying.

And to keep me honest, I’ll share the basic thoughts with you: some thoughts from my recent talk about women in the workplace; more on VDI use cases; what’s been consuming my time recently and keeping me from blogging — budgets; the impostor syndrome/not a “real” CIO; immersion into the world of VDI; CIOs as Jean Luc Picard (“make it so”); guilt; vendor sales calls — of which I get a *lot*; and defining problems/disguising solutions as needs.

Which one(s) do you want to read about?

Virtual Desktops: Persistent, Non-Persistent, or….Both?

Use cases are critically important in virtual desktop implementations. Identifying and understanding your various use cases will help you make more effective decisions about your VDI architecture — the underlying platform and management technologies, broker, clients, communication protocols (RDP, PCoIP, etc), storage requirements, and so on. Some use cases may be better supported by one system design and set of technologies, other use cases may work better with an alternate design and/or technologies. And no matter how badly you want to be 100% virtual, some use cases may not be well suited for VDI at all. At least not yet.

While the specific details of each use case will vary, all use cases can generally be distilled down to two types — persistent or non-persistent. Non-persistent desktops refresh themselves to their original state on shutdown/startup; they don’t maintain user data, personalization settings, or any other changes. Persistent desktops do, and therefore can be more complicated to work with, often requiring more storage, a potentially different backup structure, and a host of other considerations ranging from how to handle access to local USB devices and printers to user needs for installing personal software and administrative rights. Which is why many institutions focus their VDI projects on non-persistent desktops.

At Menlo, we are rolling out both types of virtual desktops, but decided to start with our simpler non-persistent ones. Or so we thought. It turns out that while our lab and learning space *do* refresh themselves on shutdown/start up (we use a software called Deep Freeze to maintain a steady state in our physical environment), and *do not* maintain user data or other personalization/changes the user makes, they have persistent attributes nonetheless. So they’re *both* persistent and non-persistent at the same time. Oy.

What makes our environment both? While we do expect our desktops to return to their original state, that original state includes a customized desktop background and specific positioning of icons on the desktop, among other things. This isn’t that difficult to do with a physical image, but in a VDI environment this spans both persistent and non-persistent attributes. To make matters even more challenging, some of the software we’re using on our presumably non-persistent desktops requires level of persistence to, well, work properly. Or at all.

These challenges are all solvable — but possibly not in the ways that you think. To manage icons we found a program called RocketDock, so instead of ordering the actual desktop icons we get rid of these with an AD script on log in and replace them with an application that serves up icons in a configuration we set at the application level. Scripting at various levels has also helped address some of our persistent/non-persistent issues. (For the record, and in the interest of full disclosure: our VDI solution is a combination of VMWare View and Unidesk, and we’ve been working with Rob Zylowski and the folks at @UnideskCorp to solve these problems. Their creativeness and brilliance in finding solutions to these challenges cannot be overstated.)

The key, in my opinion, to addressing at least some of these issues is understanding what need you’re actually trying to address, and then figuring out the best way to solve that problem. And I don’t mean the need for ordered icons or specific desktop background — those were just solutions that were designed to meet the need in your current environment. There might be different, possibly even better, ways to solve it in a new virtual environment. Or you may find that because of the differences in the environment, the need simply no longer exists.

Which brings me right back to….yep, you guessed it….use cases. Knowing and understanding them is *key*. Once you’ve figure out “how” you do things for each use case, don’t forget to ask “why”. And when you think you’ve got them all figured out, go back to the drawing board and take a look at them again. And again.

We’ve Come a Long Way, Baby?

March is Women’s History Month, and I was asked to speak at a campus Women’s Club luncheon. Just provide a little info on yourself and your experiences, and then let the participants ask some questions, the club coordinator said.

So I got to thinking…what experiences should I share? Should I share the recent Obama report that says women have higher graduation rates than men, but still make 75-80% of what men do? I’ve had experience with that. Or perhaps the fact that women lag behind men in science and technology fields, and recent research shows that unconscious sexism may play a part in that? I’ve had experience with that, too.

I don’t want to portray a negative image of my own work experiences specifically, or the plight of women in the workplace generally. Overall, I’ve had a tremendously successful career and have been very fortunate to have many supporters, advocates, and mentors — most of whom were men. But I do want to be realistic, and the truth is that despite my many successes, I’ve had to wade through the sexism (inadvertent and covert, alike), unequal pay, differing expectations, and more to get where I am today.

It saddens me to  hear — from men and women alike — that we’ve come a long way, as if this somehow justifies the current state of things and makes it more acceptable. Really? Relative pay has increased at a snail’s pace over the last 30+ years, and we may actually be losing ground in the STEM disciplines. Perhaps we have come far in some areas, but not so much in others. And there are still, in the the immortal words of Robert Frost, “miles to go before [we] sleep.”

Want Better IT Service Design? Make CIOs Teach…

A little background for this post…I was recently accepted as a mentor in the Technovation Challenge program, which kicked off this week. The program’s goals are near and dear to my heart: promote women in technology. It’s an exciting 9-week program where teams of high school girls develop a business plan for, and actually build, a fully functioning prototype Android app — and then pitch it at the end of the program to a panel of outside experts. Totally cool! But I digress…

Tonight we discussed a five-step design process that the girls are going to use when developing their apps — Empathy, Define, Ideate, Prototype, and Feedback. The steps aren’t anything revolutionary or new — they just represent a good solid design process. But sometimes it’s good to get reminded about the basics.

So I got to thinking about “empathy” in the context of what we in IT do every day. Empathy, of course, is “the intellectual identification with or vicarious experiencing of the feelings, thoughts, or attitudes of another” (dictionary.com). Or, as one of our girls said tonight, “putting yourself in someone else’s shoes.”

I think we’d all like to believe that we’re empathetic to our users. We try really, really hard to understand the needs of our users; to identify with their experiences using the technology we provide. We can — and do — ask questions, watch interactions and behavior, and make careful *observations* — not *interpretations* about what we see. But is that enough to impact the design of our technical services in a meaningful way?

In the fall, I got the chance to truly put myself into our faculty’s shoes when I taught a semester-long course on Web Design. I’ve given a lot of presentations, conducted numerous trainings, and talk extensively to faculty about their experiences with and use of technology in the classroom. And *none* of that compared to the first-hand experience I gained teaching in the classroom.

There were a number of issues I experienced that I would have considered minor had I heard about them from faculty, prior to my own experiences. My first day of class the printer was out of paper. Another day the YouTube streaming was somewhat halted, buffering every so often for a second or two. And then there was the issue with the plug-ins, the sound dial, and so on — and all, truthfully, were minor from a technical perspective.

I’ve seen help desk tickets like these before, and have been empathetic to them. But I’ll admit, a little, teeny, tiny part of me has felt like you have to expect some level of…je ne sais quoi…when it comes to technology, and you just have to be flexible and, well, deal with it. Not that I’d ever tell someone to just deal with it, mind you. I swear.

While these little issues became quite large issues when I was standing in front of a class trying to teach, what surprised me most about my experience was my ability — or lack thereof — to use the technology in place for me. Quite simply, I couldn’t. I’m a highly technical user, but when it came to using our technology in a real-world setting I couldn’t do much more than use the most basic of tools — the computer and projector. The classroom is nicely equipped with software to allow faculty to show their screen to students, or show one student’s screen to the class — both of which would have been helpful in my class. While I’ve actually pitched the benefits of this program to our faculty, and conducted some of the training on it, I couldn’t work it “on the fly” when I was trying to also teach on a different subject matter.

So what does this have to do with empathy? We can *vicariously* experience what our users do and gain some level of empathy, but nothing compares to the real thing. I look at our classrooms and our instructional support tools in an entirely new way because of my experiences last semester.

If institutions want to build better relationships between their faculty and IT — a connection that is generally presumed to be shaky, at best — I believe they can do no better thing than put their CIOs and senior IT managers into the classrooms to teach. Having that experience did not make me an expert in teaching or in the needs of faculty — far from it — but it did provide me with a much better framework for asking questions, observing behavior, and intellectually identifying with our faculty. And that’s the goal, right?


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 27 other subscribers