“We’re doing this for your own good, you’ll be better off and you’ll thank us for it.”
Um, no. Probably not.
“We’re doing this for your own good, you’ll be better off and you’ll thank us for it.”
Um, no. Probably not.
Here are a couple of stories I’d like to share on the concept of shared understanding. The first, a conversation between me and my son, Zeke, highlights the importance of being aware of and understanding the context of a situation from different people’s perspective. The second, a story relayed to me by a friend, shows the importance of ensuring shared understanding in a shared context and how easy it can be to not have it. Even when you think you do.
You know the way home, right?
My son, Zeke, and I were in Milwaukee for the Midwest Gaming Classic. As we were walking from the hotel to the car getting ready to head home on Sunday morning, Zeke asked me, “You know the way home, right?”
A reasonable question, and one that I could honestly answer with yes. Which was the right answer, though as it turns out that was not the question he was actually asking. What Zeke was really asking was, “Can we listen to the radio on the way home?” A little background may be in order.
On the drive up to Milwaukee I used Google maps on my phone, connected to the car audio system, as a navigator to get us from home to the hotel. Because I wanted the navigation to come through the audio system, we were limited to listening to music or podcasts (or other apps) from my phone and couldn’t listen to the radio. So when Zeke asked if I knew the way home, he was really wondering if I needed to use Google maps to get us home.
If I had said, “No, I don’t know the way”, then he would have known that we wouldn’t be able to listen to the radio, and if I said “Yes” then we could listen to the radio. (If you’re wondering, we listened to a couple Premier League soccer matches and the first half of the Cardinals / Braves game.)
Because of our long history together (25 years now) I knew that he didn’t care whether or not I knew the way home. He knew that if I didn’t, I would simply use Google maps as my navigator. I did know that he cares about what we listen to in the car, that he prefers to listen to talk (usually NPR) or sports over music, and that he usually watches Premier League soccer on TV on Sunday mornings.
Understanding where he was coming from allowed me to answer the question he actually wanted an answer to. It’s probably worth noting at this point that Zeke is autistic and, while able to communicate verbally, has some unique challenges and methods in his communications. Developing this shared understanding has been critical for both of us to understand each other.
DO NOT LET GO, YOU ARE NOT ON BELAY!
Some friends were climbing at Horseshoe Canyon Ranch in Northwest Arkansas earlier this year. It was an especially nice weekend, so there were a lot of people out taking advantage. There was one route my friends wanted to attempt so they waited while another pair were climbing. While most of my group of friends were relaxing and just generally hanging out, one of the group – we’ll call him Dave – was watching the other pair climb. And good thing he was.
When a climber reaches the top of a route on lead, he will typically clip directly into the anchors and go off belay so that he can fix a rappel to get back down. Sometimes, though, he will set some gear and run the rope through the gear so he can be lowered down and the next climber can then top rope the route.
In this case, the climber did neither; instead, he down climbed to the last piece of protection he had placed on the way up, apparently with the expectation that his belayer would then lower him from that point. The belayer, however, was not aware of any of this, having expected that the climber had gone off belay at the anchor. (I think you can see where this is going.)
Dave, watching this unfold, saw that 1) the belayer had taken the climber off belay and 2) the climber was getting ready to let go of the rock and lean back to be lowered to the ground, which meant that 3) the climber was just about to plunge to his death. At which point Dave shouted at the top of his lungs, “DO NOT LET GO, YOU ARE NOT ON BELAY!”
The route this pair was climbing was an overhanging 5.11c, meaning that this was an experienced pair of climbers (5.11c is hard) and that when the climber is on the top half of the route the climber and belayer cannot see each other. The typical exchange when the climber gets to the top and clips into the anchor would be for the climber to shout down, “Off belay” (to let the belayer know that they can take him off belay) and the belayer shouting back up, “Belay is off” to make sure that the climber knows he is on his own.
In this case, the climber shouted something down, the belayer thought it was “Off belay”. The pair thought they had a shared understanding of the situation, but they obviously did not. The climber had broken from the routine, while the belayer was following the routine because she didn’t know of the climber’s change.
Fortunately for this pair, and everyone at the crag that day, Dave’s warning was in time and successful in stopping the climber from letting go and leaning back.
The concept of shared understanding is important in all aspects of life, personal and professional, whenever more than one person is involved. But there is no real definition of what “shared understanding” entails; it’s more of a “know it when you see it” kind of thing. These two stories, hopefully, show what shared understanding might mean in different situations; one being a situation where two people are coming from a different context and one where they are coming from the same context.
Would love to hear some of your stories about shared understanding, or the lack thereof.
A few weeks back at EMWCon 2016, Angelika Müller from Hallo Welt! spoke about the sales life cycle for enterprise wiki services, featuring their Blue Spice MediaWiki Enterprise Distribution. During her talk, Angelika hinted at a project they had completed for some customers* involving WebDAV. Unfortunately, the constraints of that engagement prevented them from speaking openly about it at the conference; the one year “gag order” was set to expire a few days after the conference.
Well, that gag order is up and the Blue Spice team invited us to join a webinar today to show of what they’ve done. Very cool stuff. (I have some screengrabs from the webinar, but they are on a different computer. I will add them in tomorrow.)
stands for “Web-based Distributed Authoring and Versioning”. It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.
Basically, it lets you interact with files on a remote web server as if they were local files. In the enterprise this typically means Microsoft Office files from a Windows computer.
To start the demo, Markus showed how you can access a wiki through Windows Explorer, with the ability to open and edit the actual wiki articles. Though this is a cool feature, as Markus noted it not an especially interesting use case. Opening a page and editing it on a text editor on your computer will be slower and more cumbersome than simply editing the page on the wiki, and you will still need to use wikitext for the content.
The really interesting, and valuable, aspect of WebDAV integration with wiki goes back to those MS Office files. With the access to the wiki through Windows Explorer, you can directly add files to the wiki through your computer file system. For example by dragging and dropping from another folder, or simply saving a new file to the Media folder (aka namespace) on the wiki.
In addition to adding files through Explorer you can open, edit, and save the file as if the file were stored locally on your computer. Which is, of course, what WebDAV does. The really great part, though, was that you can also open the file from within the wiki, edit it, and save it directly back to the wiki. No downloading, editing, and then uploading again. If you’ve ever had to do that, you know how nice this feature is. In both cases, the versioning info is maintained on the file’s wiki page.
One of the challenges with the way MediaWiki handles files, of course, is that they typically all go into a single namespace, such as “File”. Not only does this make it hard to keep things organized, all of the files have the same permissions. To address this, Markus demonstrated the Extension:NSFileRepo in action.
The NSFileRepo extension restricts access to upload and read files and images to a given set of user groups associated with protected namespaces. Using this extension (within the security limitations noted above), you can protect not only pages and areas of your wiki, but also any uploaded images or files within those namespaces.
The WebDAV integration can be used on a “vanilla” MediaWiki install, but some of the features Markus demonstrated today are specific to Blue Spice. Installation is a bit more involved than simply installing an extension; the way that WebDAV works requires some web server configuration as well.
tl;dr Using WebDAV integration with MediaWiki provides a much more user friendly experience for uploading and working with files on MediaWiki.
* They built the WebDAV integration as a crowdsourced project, where several customers contributed to the project to ensure it was fully funded. Those customers agreed to making the project available to general customers, but only after a certain amount of time (a year) had passed. An interesting approach to getting open source work funded, one I’ll probably come back to again later.
In his talk at the Enterprise MediaWiki Conference 2016 in New York Jason Bock informed about some social aspects they built into the system also implemented by the functions of Semantic Mediawiki. […]
Marketing inherited a model of exchange from economics, which had a dominant logic based on the exchange of “goods”, which usually are manufactured output. The dominant logic focused on tangible resources, embedded value, and transactions. Over the past several decades, new perspectives have emerged that have a revised logic focused on intangible resources, the co-creation of value, and relationships. The new perspectives are converging to form a new dominant logic for marketing, one in which service provis
When did corporations becomes instruments of value extraction instead of value creation?
Behind the Federal Front Door: Citizen-Centered Service Design (Brad Nunnally)
Ninety-four percent of federal IT projects are over budget / schedule. Huge budget (in the $Bs), most of maintenance and legacy.
Brad is from 18F. All products they create are open source (free as in beer), they provide services to other federal agencies. Has grown quite a bit over last year or so, up to 190 people. Many on “temporary” assignment while on sabbatical from their regular job.
Brad is currently working on the Federal Front Door.
Contrary to what many think, the Federal government is not a monolithic organization, it is made up of many (many) independent organizations, each with their own “CEO”, “CTO”, etc. How do you design a consistent experience across all of government?
“It’s too good to be a Government website”, some people’s reactions, so they need to to put in a bit of artificial friction to make it easier to accept.
Met with people in different areas around the country. Conducted interviews and diary studies. Focused on life events with general users. Diary study with librarians. (Librarians can’t help people on the web, just point them to the computers?)
They’ve learned a lot, not many answers yet. Three main problems:
nts: the problem is much much larger than the digital front door; the actual citizen facing services need significant work.
People don’t trust the government with their information. But the government already has all of your information. Why do they keep asking you for the same information over and over? FAFSA is a good example of one org sharing / pulling with another.
labs.usa.gov, standards.usa.gov, github.com/18F
How to design a service – Intro to Service Design (Nathan Lucy)
What is a service: the use of one’s competences for the benefit of another. (from the body of knowledge known as “common sense”.) The fundamental basis of exchange, the foundation of economics.
Money is a medium for exchanage (see “Google bus”). A means of transaction, not storage.
Beneficiary is always a co-creator of value. There is no value without a consumer, and they always determine the value.
No one wants a 1/4″ drill, they want a 1/4″ hole. Many ways to get a hole, to deliver that service. Buy the drill, HILTI, use a knife, etc.
Research. Synthesis. Ideation. Prototyping. Testing.
We used appear.in as a way to share part of the presentation, need to learn more about that.
Next meetup – 6 October.