Total aside, but the chocolate milk and coffee concoction he describes in one of the pictures was also my drink of choice. I dubbed it the Microsoft Mocha, although I don’t think the name caught on.
When users never use the features they asked for
111–120 of 228 posts
Re: When users never use the features they asked for
#112Total aside, but the chocolate milk and coffee concoction he describes in one of the pictures was also my drink of choice. I dubbed it the Microsoft Mocha, although I don’t think the name caught on.
It definitely fueled the pursuit of multiple good (and bad) ideas during my time in Redmond.
Re: When users never use the features they asked for
#113We found (in the world of building Hyperscan, a high-performance regular expression matching library) that asking users what features they wanted was a disaster.
You have to ask them what they want to achieve. Their suggestions as to how to do it were almost always terrible: partly, they don't have the domain knowledge to know what's going to be simple and practical vs complex and nasty.
Also, they usually have a comparatively clear picture of what they want to achieve, but their notions of how best to break that into "your problem (library)" vs "our problem (app)" are often very naive - you wind up owning way too much of the problem (usually), or occasionally going in the other direction and not really getting enough context information into your library.
Re: When users never use the features they asked for
#114One pitfall I’ve seen user researchers fall into is they are obsessed with recruiting a fresh sample of users for their ongoing rounds of user interviews.
This recruitment requirement skips much of the understanding of user needs, priorities, workflows, etc that came from previous rounds of exploration and testing.
The real value comes when you gather a small but roughly representative sample of users and collaborate closely with them on the development of feature(s).
For example, I recently built a ‘User Advisory Board’ to guide the development of internal tools at a large organization (using software I developed for that purpose).
This subset of users was engaged throughout the development process - collaborating with designers and engineers throughout - resulting in a finished product that was closely aligned with user needs.
I don’t have data to back this up, but I got the sense users were more satisfied with the end result because they felt they had a hand in ‘co-creating’ it (aka ‘the IKEA effect’).
OP claims they did this early on, but my comment is pointing to a larger issue I’ve witnessed that may help those reading this to avoid the issue of users not adopting features they asked for…
Re: When users never use the features they asked for
#115I once stayed at work for 36 hours straight to finish assembling a batch of circuit boards for a customer's prototype. I dropped them off at FedEx for next day AM shipping right before they closed on a Saturday and felt pretty good to just barely make the deadline!! Well Monday morning, the customer assembles the first prototype and it lights on fire. Turns out there were lots of other problems and all my work was fo…
> all my work was for nothing
No way. Not for nothing! The customer did not have the added problem of late circuit boards. Even if they could not build their prototype, you did good.
Re: When users never use the features they asked for
#116So I want to share a story about user asking for a feature then not using it. I run an email forwarding services( https://hanami.run ) basically you add your domains in and add some records. We had this one heavy users who has like hundreds of domains. So our UI isn't design for that. Who has hundreds of domains? So they approach and asked us for a way to organize those domains into a hierarchy structure. All good. T…
It's a pretty cool tool. You just got a new customer :)
Re: When users never use the features they asked for
#117Earlier quoted context omitted.
Yeah sounds like the lesson here is that nobody reads the update messages.
If quantum scientists thought the slit experiment was exciting, they should study IT user preferences and be amazed how depending on the mode of communication/observation, customers will both scrutinize every letter you write while simultaneously not reading it at all, will know every wrong pixel of your UI but not know where the button for "Thing" (labeled "Thing") is, and how anything you make is somehow the best w…
It is a special case of Morningstar's law, you can't tell people anything. http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
Re: When users never use the features they asked for
#118Earlier quoted context omitted.
I can't edit my post anymore-- before someone realizes my mistake, it was the XBox One, not the 360. Rails barely existed at the time of the XBox 360 development.
Thanks for updating! I was a little confused since Heroku wasn’t around before the 2005 launch of the Xbox 360, but figured it was shorthand for something else. Given the Xbox One SOC had a lot more security in mind, I could see how Microsoft was more cautious about these things. [1] [1] https://m.youtube.com/watch?v=U7VwtOrwceo&feature=emb_title
Just a lapse of memory and thanks for the benefit of the doubt. Another commenter mentioned turbolinks and I was like "whoooaaaa yes I used that and this timeline doesn't line up at all." This lead to a long internal discussion about when exactly did I play Bioshock and does that line up with my memories :-)
I guess I don't mind talking about it so much-- we made a sub $1 component that could compress certain specific waveforms and play them back-- the trick was that they were highly structured, so the compressed data basically just parameterized the silicon in what might be considered to be essentially an assembly instruction-- frequency, carrier wave, data to be sent, etc. The chip then would generate the signal and you could shove it out the electromagnetic radiator of choice with a little amplification a diode and couple of resistors. The problem with these signals was they required very precise timing-- they weren't super complex, but not something a general CPU could handle-- the variability in the timing was too high.
Now yes, you could use a general purpose DAC and an amp and generate the signals, but we sold you a turnkey thing-- with 10 lines of code you could be transmitting signals and the whole thing only use a few kb of ram.
It wasn't super high tech, but our value add was high. I'd say most of the major electronics companies used our chips at one time or another.
Re: When users never use the features they asked for
#119I'll have to jump out and point out that this is exactly the type of study that I feel the academia nowadays more or less are forced to perform, but at the same time have questionable setup and limited impact.
Overall the study is performed a very limited time frame, with a last portion of the data analysis performed through emailing back and forth. The research scope is limited to 300+ organization, which in fact has 30000+ engineer in total. And the tool was developed without much of normal industry standard understanding, aka, introduce a code analysis tool requiring users explicitly invoking it (I think anyone who is at a typical senior level in large Corp knows that without management pushing, such change is never going to work). The mentors of the author might be full time researcher?
I am not really nitpicking or condescending. I am dismayed by the waste of time and effort on both sides.
I'll read the paper later. But I suspect it would be basically some well known facts in the dunstry...
Re: When users never use the features they asked for
#120Earlier quoted context omitted.
The OP wasn't re-writing them. Instead the OP fed the old version into a tool (Disassembler) which spat out terrible source code, worse than the original with no comments and bad variable names. This was the only way to get source at all. Then they made the disassembled source compile in a really nice way. Finally the boss asked them to make huge changes to this horrible source with time pressure.
Pretty much this. A lot of the work would have been roughly equivalent to trying to de-minify some JS. With a modern IDE the task would have been a lot easier. I don’t know if Eclipse had refactoring assistance built into back then, but if it did, I’d never even heard of the idea. I was sitting on not much more than a year of programming experience at the time.
Eclipse had refactoring from the start. It was pretty advanced IDE for the time.