Teaching

Visual Homework Policy

1
6 months ago
by Seth Battis in

Click to download a PDF of this. Feel free to reuse it — just let me know, especially if you make any particularly effective tweaks.

This policy has been gestating for some time, and I started to formulate it in conversation with one of my students who had had a brush with the academic dishonesty fairy. I presented it in class last week, and I realized that it is as good a representation as I have of my homework policy. I’m not really interested in coming up with a suitably punitive formula for docking grades for lateness, and I don’t particularly care about negotiating reasonable extensions. Mostly, like my students, I just don’t want to be bothered. But, by golly, there are things that bother me, and it would be good to steer clear of them. And it’s worth knowing how they rank in my worldview. And this expresses it.

Better not to do your work than to cheat or plagiarize to finish your work. Better to ask for an extension at the last minute than to just not do the work. But noticeably better to ask for the extension in a timely manner.

I’m pretty sure that this both made sense to and stuck with my ninth graders.

Transmogrifying those Google Reader JSON dumps into something useful

9
1 year ago
by Seth Battis in , , ,

For the last few years (my JSON feed tells me: since 2008), I have been tagging and annotating articles of interest as they passed before my eyes in Google Reader. This served a two-fold purpose:

  1. I could find them again later, easily, because they were tagged and annotated.
  2. I could share an RSS feed with those annotations to particular interest groups that I worked with (e.g. anything tagged “for robotics” would show up on my advanced computer science class’ portal page, or anything tagged “for academic computing” would show up on my school home page).

This was a great way to share (and manage) resources. Granted, much of what passed before my eyes in Google Reader was trivial and not of lasting value, but this filtering allowed me to hang on to at least a few gems for future reference.

And then Google Reader got the Google+ treatment and sharing items broke. But you could download a JSON dump of all the items that you had ever shared. It wasn’t entirely clear what you could do with this JSON dump, but… there it was. And then: I realized that all of my other information is stashed on my web server (and that I have become increasingly distrustful of relying on cloud services to maintain my data and workflows — e.g. my weekly backup of all my Google Docs… just in case).

Wouldn’t it be handy to import that JSON feed into a new blog on my server? So I wrote a PHP script that converts (at least my) Google Reader JSON dump into an XML file that WordPress can import as a list of posts. With the tags and annotations converted over. In fact, with all of the data in the JSON dump embedded in the XML file (although WordPress doesn’t read all of it).

This comes with a few caveats:

  • For items that came from blogs with a full feed, the result is a republication of the original post — which feels ethically dubious to me. (I have made my new blog of Google Reader shared items private, so that I have the data but I’m not sharing it with the world).
  • I’ve made guesses as to how to treat some of Google’s data. Reasoned, educated guesses, but guesses nonetheless. For example, I’m not super-clear on which dates in the file correspond with what events — does a publication date refer to when the item was shared or the original post was posted?
  • I’ve added in some arbitrary (and therefore, ideally, eventually, configurable) WordPress tags to make the import go more smoothly. Where I have done that, I mark it in the script as a TODO item. (And, in truth, I didn’t really test to see if all of these items were necessary.)
  • The original authors of the posts are transfered to the XML file, which means that when the actual import into WordPress is done, you will have the option to either laboriously create a new user for each distinct author or simply revert authorship to the currently logged-in WordPress user. It doesn’t seem like WordPress has a format for exporting or importing users (or, at least, my cursory search didn’t find it). Clearly an ancillary SQL query could be generated that pre-populated the WordPress database with the users that the XML file refers to. But I haven’t bothered to do that.
  • You’ll need your own PHP-compatible webserver to run the script, since I have been quick and dirty and simply imported the JSON file from and exported the XML file to the script’s local directory. And I have no interest in setting up my world-facing webserver to take the traffic hit of processing other people’s multi-megabyte JSON dumps.
With that said, here is the script, as it stands this morning.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260

/**********************************************************************
 * Google Reader to Wordpress
 *
 * 2011-11-27
 * Seth Battis (seth@battis.net)
 * 
 * This script takes the output of Google Reader's JSON export of
 * shared items and converts it into an XML file that can be imported
 * into a Wordpress blog as posts. All of the data in the original JSON
 * file is preserved in the XML file, either by transfering it to
 * an appropriate format (e.g. Google Reader categories are converted
 * to WordPress post tags) or simply as an additional XML tag (e.g. the
 * Google Reader commentInfo metadata for recent shared items). In
 * situations where actual data has to be converted to make it readable
 * for WordPress, the original data is included as the JSON attribute
 * of that tag (e.g. timestamps and categories).
 *
 * As currently written, the script looks in its local directory for
 * Google Reader "shared-items.json" file and generates a matching
 * "shared-items.xml" file, also in its local directory.
 *
 * There are a number of potentially configurable (i.e. arbitrary)
 * values marked as TODO.
 *
 * Caveat emptor: this has been tested against my ~1000 item Google
 * Reader shared items feed and on my WordPress 3.2.1 site. I would
 * presume that it should work fairly well for others, but make no
 * guarantees!
 *********************************************************************/
 
/* returns a Wordpress slug-version of the given text (only
   alphanumeric characters and dashes) */
function sluggify($text)
{
	return preg_replace("|[^a-z0-9]+|", "-", strtolower($text));
}
 
/* SimpleXML doesn't really support namespaces unless you force it */
$xml = '<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0"
	xmlns:excerpt="http://wordpress.org/export/1.1/excerpt/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:wp="http://wordpress.org/export/1.1/"
></rss>';
$rss = new SimpleXMLElement($xml);
$namespaces = $rss->getDocNamespaces(true);
 
/* load the Google Reader JSON file */
$file = file_get_contents("shared-items.json");
$json = json_decode($file, true);
 
/* Wordpress will choke if our post names aren't unique, so we track
   them separately */
$post_names = array();
 
/* header information describing the file itself */
$channel = $rss->addChild("channel");
$channel->addAttribute("direction", $json["direction"]);
$channel->addAttribute("id", $json["id"]);
$channel->addAttribute("self", $json["self"][0]["href"]);
$channel->addAttribute("author", $json["author"]);
$channel->addChild("title", $json["title"]);
$channel->addChild("link");
$channel->addChild("description");
$pubDate = $channel->addChild("pubDate", gmdate("D, j M Y G:i:s O", $json["updated"]));
$pubDate->addAttribute("json", $json["updated"]);
$channel->addChild("language");
$channel->addChild("wxr_version", "1.1", $namespaces["wp"]);
 
/* run through the list of items and add them to the XML */
foreach ($json["items"] as $item)
{
	$rssItem = $channel->addChild("item");
 
	/* a bunch of Google Reader-specific metadata */
	if (isset($item["isReadStateLocked"]))
	{
		$rssItem->addAttribute("isReadStateLocked", $item["isReadStateLocked"]);
	}
	$rssItem->addAttribute("crawlTimeMsec", $item["crawlTimeMsec"]);
	$rssItem->addAttribute("timestampUsec", $item["timestampUsec"]);
	$rssItem->addAttribute("id", $item["id"]);
	if (isset($item["commentInfo"]))
	{
		while (list($commentInfoKey, $commentInfoValue) = each($item["commentInfo"]))
		{
			$commentInfo = $rssItem->addChild("commentInfo", $commentInfoKey);
			$commentInfo->addAttribute("permalinkUrl", $commentInfoValue["permalinkUrl"]);
			$commentInfo->addAttribute("commentState", $commentInfoValue["commentState"]);
		}
	}
 
	/* annoyingly, not every item has its content in the content
	   element -- sometimes it's in the summary element (and once in a
	   while, it's just not there). I think this is an artifact of how
	   the original RSS feeds were constructed. I think. */
	if (isset($item["content"]))
	{
		$content = $item["content"]["content"];
	}
	else if (isset($item["summary"]["content"]))
	{
		$content = $item["summary"]["content"];
	}
	else
	{
		$content = "";
	}
 
	/* sometimes items don't even have titles */
	if (isset($item["title"]))
	{
		$rssItem->addChild("title", $item["title"]);
	}
 
	/* most items store the original linkback information in the
	   alternate element -- Wordpress won't honor this link tag when
	   it's imported (i.e. it won' treat it like the Daring Fireball
	   feed), so I have embedded a more descriptive linkback after the
	   annotations at the start of the content, using some information
	   from the origin element. The linkback is in the
	   "google-reader-alternate-href" div (for easy CSS-wrangling!) */
	if (isset($item["alternate"]))
	{
		$rssItem->addChild("link", htmlentities($item["alternate"][0]["href"], ENT_COMPAT, "UTF-8"));
		$content = htmlspecialchars("<div class=\"google-reader-alternate-href\"><p>Originally posted at <a href=\"{$item["alternate"][0]["href"]}\">{$item["origin"]["title"]}</a></p></div>", ENT_COMPAT, "UTF-8") . $content;
	}
 
	/* I haven't bothered to figure out if the dates are really GMT or
	   localized -- GMT was an easier assumption to make */
	$pubDate = $rssItem->addChild("pubDate", gmdate("D, j M Y G:i:s O", $item["published"]));
	$pubDate->addAttribute("json", $item["published"]);
 
	/* not every item has an a author, either -- again, an artifact of
	   the original RSS feeds */
	if (isset($item["author"]))
	{
		$rssItem->addChild("creator", $item["author"], $namespaces["dc"]);
	}
 
	/* annotations were tricky -- I have added them as their own XML
	   tags _and_ inserted them within a "google-reader-annotation" div
	   at the top of the post content (to match the original format on-
	   screen). All of the original data is preserved in the XML tag,
	   with an ID that matches the embedded div ID. */
	foreach($item["annotations"] as $annotation)
	{
		$annotationHTML = htmlentities("<div id=\"" . md5($annotation["content"] . $annotation["author"]) . "\" class=\"google-reader-annotation\"><blockquote><p>{$annotation["content"]}</p><p class=\"author\">{$annotation["author"]}</p></blockquote></div>", ENT_COMPAT, "UTF-8");
		$content = $annotationHTML . $content;
		$rssAnnotation = $rssItem->addChild("annotation", $annotation["content"]);
		$rssAnnotation->addAttribute("id", md5($annotation["content"] . $annotation["author"]));
		$rssAnnotation->addAttribute("author", $annotation["author"]);
		$rssAnnotation->addAttribute("userId", $annotation["userId"]);
		$rssAnnotation->addAttribute("profileId", $annotation["profileId"]);
		$rssAnnotation->addAttribute("profileCardParams", $annotation["profileCardParams"]);
	}
 
	/* again, sometimes content is in content, sometimes it's in the
	   summary element */
	$rssContent = $rssItem->addChild("encoded", $content, $namespaces["content"]);
	if (isset($item["content"]))
	{
		$rssContent->addAttribute("direction", $item["content"]["direction"]);
	}
	if (isset($item["summary"]))
	{
		$excerpt = $rssItem->addChild("encoded", $item["summary"]["content"], $namespaces["excerpt"]);
		$excerpt->addAttribute("direction", $item["summary"]["direction"]);
	}
 
	/* more Google reader metadata, this time about the original feed
	   that the item came from -- which is used above to format the
	   linkback that is embedded a the start of the content */
	$origin = $rssItem->addChild("origin");
	$origin->addAttribute("streamId", $item["origin"]["streamId"]);
	$origin->addAttribute("title", $item["origin"]["title"]);
	$origin->addAttribute("htmlUrl", $item["origin"]["htmlUrl"]);
 
	/* it's not clear to me whether the published or modified date is
	   when the original post was published or when the item <span class="hiddenGrammarError" pre="item ">was
	   shared</span> -- I think when published refers to when it was shared. */
	$postDate = $rssItem->addChild("post_date", date("Y-m-d G:i:s", $item["published"]), $namespaces["wp"]);
	$postDate->addAttribute("json", $item["published"]);
	$rssItem->addChild("comment_status", "open", $namespaces["wp"]);	// TODO make configurable
	$rssItem->addChild("ping_status", "open", $namespaces["wp"]);		// TODO make configurable
 
	/* make a Wordpress friendly title slug for the post */
	if (isset($item["title"]))
	{
		$slug = sluggify($item["title"]);
	}
	else
	{
		/* if no title, generate the slug from the timestamp */
		$slug = date("Y-m-d-G-i-s", $item["published"]);
	}
 
	/* make sure that our slug  is unique -- add a counter to the end
	   if it is not, and track those counter values in $post_names[] */
	if (isset($post_names[$slug]))
	{
		$post_names[$slug]++;
		$slug .= "-" . $post_names[$slug];
	}
	else
	{
		$post_names[$slug] = 0;
	}
	$rssItem->addChild("post_name", $slug, $namespaces["wp"]);
 
	/* more Wordpress metadata -- all of which could be tweaked */
	$rssItem->addChild("status", "publish", $namespaces["wp"]);	// TODO make configurable
	$rssItem->addchild("post_parent", 0, $namespaces["wp"]);	// TODO make configurable
	$rssItem->addChild("menu_order", 0, $namespaces["wp"]);		// TODO make configurable
	$rssItem->addChild("post_type", "post", $namespaces["wp"]);	// TODO make configurable
	$rssItem->addChild("post_password", "", $namespaces["wp"]);	// TODO make configurable
	$rssItem->addChild("is_sticky", 0, $namespaces["wp"]);		// TODO make configurable
 
	/* convert categories to post tags -- nota bene that Google Reader
	   has conflated the reader's categories with the original post's
	   tags, creating a... mish-mash. */
	foreach($item["categories"] as $category)
	{
		if (!preg_match("|.*/com\.google/.*|", $category))
		{
			$cleanCategory = $category;
			$cleanCategory = preg_replace("|user/\d+/label/(.*)|", "$1", $cleanCategory);
			$rssCategory = $rssItem->addChild("category", htmlentities($cleanCategory, ENT_COMPAT, "UTF-8"));
			$rssCategory->addAttribute("domain", "post_tag");
			$rssCategory->addAttribute("nicename", sluggify($cleanCategory));
			$rssCategory->addAttribute("json", $category);
		}
	}
 
	/* add comments -- note that for privacy reasons, while the
	   commenter's metadata is added as an XML tag, it is not embedded
	   in the Wordpress-readable wp:comment tags */
	foreach($item["comments"] as $comment)
	{
		$rssComment = $rssItem->addChild("comment", "", $namespaces["wp"]);
		$rssComment->addAttribute("id", $comment["id"]);
		$commentContent = $rssComment->addChild("comment_content", $comment["htmlContent"], $namespaces["wp"]);
		$commentContent->addAttribute("plainContent", $comment["plainContent"]);
		$author = $rssComment->addChild("comment_author", $comment["author"], $namespaces["wp"]);
		$author->addAttribute("userId", $comment["userId"]);
		$author->addAttribute("profileId", $comment["profileId"]);
		$author->addAttribute("profileCardParams", $comment["profileCardParams"]);
		$author->addAttribute("venueStreamid", $comment["venueStreamId"]);
		$commentDate = $rssComment->AddChild("comment_date", $comment["createdTime"], $namespaces["wp"]);
		$commentDate->addAttribute("modifiedTime", $comment["modifiedTime"]);
		$rssComment->addAttribute("isSpam", $comment["isSpam"]);
	}
}
 
/* dump the converted XML out as a file */
header ("Content-type: text/xml");
echo $rss->asXML();
file_put_contents("shared-items.xml", $rss->asXML());

Custom Software

0
2 years ago
by Seth Battis in

One of my colleagues, Matt Zipin (in fact, my high school computer science teacher), just sent me a link to an iPhone app that his current student, Ari Weinstein put together. It was one of those rare moments of seeing a piece of software and thinking, “This… this is exactly what I have been looking for! It’s almost like they had me in mind when they wrote it!”

Perhaps unsurprisingly, I had this reaction because, in fact, Ari has written an application that I suggested. Based on my work at St. Grottlesex as a Thirds’ basketball coach. I had been running practices using the timer and counter apps separately on my iPhone. Which was workable. But unwieldy. Enter.. Ari’s Basketball Timer app, which elegantly and cleanly combines these two tools into a single screen.

I think my favorite part of the app is something that you can’t see, that you can only experience: starting the Time out Timer stops the main clock, and starting the main clock stops the Time out Timer. How simple. How elegant. How easy it would have been to skip over.

Thank you Ari and Matt!

Developing for the App Store with High School Students

6
2 years ago
by Seth Battis in ,

I actually really, really want to document some of our projects that we’re working on this year in a great deal more detail. But, for now, I am simply publishing my notes from a conversation that I just had with Apple Education about the legalities of having high school students develop for the app store.

So… I just got off the phone with Apple Education (they were following up on an iOS in Education event a few months ago that I had actually missed). But: I did get the straight dope on Apple Developer accounts and high schools:
  • University accounts are just that: for higher education. Non-negotiable.
  • There are really three levels of developer that are pertinent to high school:
    • Free — they can download Xcode and use the iPhone simulator.
    • Individual ($99) — Same as free, plus they can use their iPhones/iPads to debug the software live (with the right certificates — I’ve found that the easiest way to set up the certificates is directly through the Xcode Organizer). My recollection is that they can have up to something like 100 devices for “debugging.” At this level, they can post apps to the App Store.
    • Enterprise ($299, IIRC) — Individual, plus the ability to manage a fleet of iOS devices (remote install and remote wipe), as well as distributing their software internally with no restrictions. I actually pressed him pretty hard on this, and he wasn’t 100% (“read the language in the agreement first”), but he thinks that it would be viable for the school to buy an Enterprise license and then say “Come by the computer lab and we’ll install our cool in-house app on your iPhone for free.” (Or for money — I don’t think they care.)
  • Apple strongly discourages the school (which would, in reality, be a single individual) signing up for an Individual developer account as the primary distribution channel to the App store for student apps. The rationale being that if a particular app makes it big, the individual who has control of that account well, has control of that account. Apple deals with account holders, not the model that the school constructed. They suggested that if a group of students wanted to band together on an app, that they should sign up as a group for an Individual account through which to distribute that app — and that they should draw up their own contract on their end for how to manage that account.
  • Students under 18 need to be signed up for the account by their parents. (Contract law — the kids are underage.)
At the end of the day, it sounded like my approach this year is basically right on the nose: I have an Individual account in my name that I use to install apps on test iPhones (and I have registered all the student iPhones as debugging devices). The students signed up for free accounts at the beginning of the year. I think what we’ll do when we release this app is sign up for a new Individual account that the students will jointly share to post the app to the App Store (something like “[Jewish Day School] App Design ’10′-’11″).

Building a Google Earth Tour in a Spreadsheet

1
2 years ago
by Seth Battis in , , ,

For the last couple of months, one of my high school classes at Jewish Day School has been working on building an interactive tool about the Six Day War for a middle school curriculum unit. They have put a lot of work into researching their data and laying it out in Google Earth, and now we’re putting together a tour of the data for the middle school students, that will also teach them a little about how to use Google Earth. It’s been enormously fun.

But. But, we now have to do some programming or some very careful recording in Google Earth to create this tour (a là Al Gore’s Climate Change tours). And my students are far more interested in the design end of things than in the coding end of things. They’re great at what they do, but niggling coding details give them head aches.

So I built a Google Docs spreadsheet, into which they can plug various pertinent information and out of which comes valid KML instructions that will define the tour. I’m a little proud of this — I don’t think that there’s anything else quite like it out there. There are three kinds of information that need to be entered:

  1. SoundCue — any audio that should be played in the background. You can either enter the whole URL to the MP3 file that should be played, or just the file name (and make sure that you enter the path in which all the files can be found on the KML Generator tab). You also need to tell us both when the cue should be played and how long it should last.
  2. AnimatedUpdate — anything that should be happening in Google Earth in terms of showing photo overlays or placemarks or polygons or what-have-you. Enter what should happen, and when (and, if relevant, for how long).
  3. FlyTo — any time we change where (or when) we’re looking at Google Earth. Enter when and how long the transition should take, and the date (and time) that we’re meant to be looking at.

The AnimatedUpdate and the FlyTo also expect the user to enter KML code — which can be copy-and-pasted from Google Earth KML exports for each transition. Happily, if something needs to happen more than once, entering the KML for the first instance will automatically populate future instances. In addition, the pauses necessary to synch up all of the action are calculated by the spreadsheet.

Update March 25, 2011: The spreadsheet above is our live work (since I kept updating the spreadsheet after this post).

The end result is both a visual timeline of the tour (helpful for debugging any weird errors) and also KML code that can be copy-and-pasted out of Google Docs and into a KML file. (Caveat emptor: depending on what you’re pasting the KML into — I like Xmplify — you may see that there is a leading and trailing quote that need to be manually deleted.)

Right now the spreadsheet can handle tours up to four minutes and 10 seconds in length (250 seconds, for those of you keeping score at home). This is because I was originally copying the KML out of the KML Orderer worksheet, and Google Docs supports pasting of up to 1000 rows in total. You’ll see that the current KML worksheet is a single cell, getting around this limitation, but I didn’t bother to extend any of the other worksheets. Just make sure you fill down all the formulas if you extend any of the sheets!

Here’s a link to a scratch copy of the spreadsheet. Feel free to copy and use it for your own purposes — let me know how you used it!

Review of OpenText Social Workplace

0
2 years ago
by Seth Battis in ,

I wrote this originally in response to a question from [the assistant head at Jewish Day School] about how I think about web tools. After writing this, I chatted with him and [my opposite number in the middle school] about how folks that are using OTSW in the middle school that are more successful — largely because they’re using it as a “gateway drug” to a web presence, rather than trying to bring an existing web presence into one place.

Here my general thoughts on selecting tools for teaching and learning, and how OTSW measures up against them. This is in no way meant as a slam on OTSW, but rather an explanation of my thought process in selecting tools with which to teach and learn, while examining the OTSW system.

In general, when looking at a tool, my first concern is how well it does its intended job — whether intended by the developer or by the user. Education is strewn with unintended, but serendipitous uses of tools never intended for that purpose: consider the military’s use of game systems for training.

Assuming that a tool does what it is intended to do, and does it well, my next concern is how well this tool will connect not just to any existing tools, but specifically to the tools that I already use (although a little forward-thinking at this moment, considering tools I might want to use down the road, is not uncalled-for).

Having looked at these two considerations, the final — and really potentially gamestopping — concern is how well this tool will support a safe learning environment for my students and myself. What “safe” means can certainly be construed in different ways, depending on the purpose of the tool (a discussion tool would certainly have different safety concerns than a research tool).

With these three concerns in mind, let us turn our eye to OTSW and our current set of web tools:

What does it do? And does it do it well?

OTSW provides a Facebook-like environment for users of our FirstClass system. It allows users to post status updates, to maintain blogs and wikis, and to comment on each other’s postings.

User status updates are handled reasonably well — there are no major surprises. The status updates are limited in length (as is true of Twitter, Facebook, SMS messages, etc.) The system will display a somewhat shortened (truncated) version of the status message to users who “follow” that user. The users cannot type a longer status update than will fit into the field, but there is no warning when the status update is longer than can be displayed to one’s followers. Potential uses for these status updates are unknown, but a creative mind could certainly come up with something. Mostly, they’re just for fun.

Consider the blogging system: the word processing system for writing posts is comparable to the FirstClass document editor in the FirstClass client, although perhaps more limited. It is also comparable to the WordPress or MindTouch wiki document editors although, again, perhaps a touch more limited: fewer formatting options, no support of the style associated with structured documents built for the web, limited capabilities for facilitating linking to other documents on the same system.

The blog commenting system is apparently “un-threaded” — or, at least, controls for turning on threaded comments are not apparent. This means that a comment posted in response to another comment is shown in the overall list of comments by date, rather than by thread of conversation. This makes complex, truly interactive asynchronous conversations about a blog post difficult, if not impossible, to read. Additionally, already read comments automatically collapse upon the return to the page (with no preference otherwise), providing limited context for new comments.

The wiki document editing system is somewhat more advanced than the blogging system, allowing for the creation of links to other pages within the specific wiki on which you’re working, although not to other wikis on the OTSW system. Additionally, three styles of structured text (body, heading and subheading) are supported on wikis, as well as a few more rich formatting options.

The organization of the wiki pages within a specific wiki on the OTSW system is flat, rather than hierarchical. While this limits the confusion associated with the page hierarchies on the MindTouch wiki, the presentation of the pages for the wiki is now as a “page cloud” in the tool bar, organized apparently by date of creation or modification (making the placement of pages unpredictable between visits). There is no clear way to move or copy a page from one OTSW wiki to another.

As [one colleague] has correctly noted, another oddity of the OTSW wiki system is that, when commenting on a page, the actual content of the page is hidden (although the other comments on the page are displayed as on the blog, along with links to different versions of the page in its revision history). This is at best unhelpful, and certainly confusing to the novice (or experienced) user.

In both the blog and wiki systems on OTSW, the ability to tag posts and pages with keywords is provided. The tagging system in beta versions of OTSW was highly vulnerable to non-alphanumeric characters in tags (e.g. “Seth’s tag” — the apostrophe in one tag rendered an entire community inaccessible). In the current version of OTSW, non-alphanumeric characters are accepted in tags for display… but clicking the tag link to view all documents tagged with that keyword has unpredictable results (in the case of “Seth’s tag” the link takes the user to a page list all documents tagged “Seth” — which does not include the pages tagged “Seth’s Tag”).

Additionally, depending on what actions have recently been taken in the OTSW environment, the tagging tool will appear in unpredictable locations or may not even be accessible. (As is also the case for initial edits of wiki pages: once posted, the user has to leave the wiki and return in order to find an Edit link for that page.) Tagging wiki pages, at least in Safari, appears to be undo-able, as the tagging tool appears the bottom of the page, with scroll bars turned off, and no save button available.

Considering the apparent purposes of the OTSW system:

  • Status updates: nothing particularly unique or different or unusual, automatic truncation without warning.
  • Blogging: limited formatting options, lack of threaded discussions, lack of ability to link even to other posts in the blog.
  • Wikis: limited formatting options, confusing discussion format, no ability to organize pages.
  • Tagging: easily broken, predictably unpredictable.

Interoperability with Other Tools

When it comes to interoperability with the OTSW communities, the highest priority concern would be how well the tools work with our existing array of tools on campus, including our blog and wiki servers and, especially, FirstClass.

The communities are stored as a special type of conference on the FirstClass server. In current versions of the FirstClass client, clicking on these conferences will open the community in a web browser. When viewed by older clients, these conferences will open to reveal a list of documents (the pages, posts, comments, etc. within the community) with an array of specialized columns reflecting how these documents would be displayed in the web browser.

When a user is invited to a community, they receive an email invitation, with a link to click to accept the invitation. Users who have not already logged in to the web interface to the communities have found that these links often are not active: they do nothing. Ideally, the result of clicking this link is that an alias to that community’s conference will appear on the user’s FirstClass desktop, giving them access to the community. Moving these conference aliases off of the desktop (perhaps into a folder called “OTSW Communities”) renders the group memberships inoperable — the conference aliases must remain on the desktop, although each functions only as a bookmark to the web interface to the communities when accessed through the FirstClass client.

When a user creates a community of their own, a new community conference is created on their desktop, and all pages, posts and documents posted to that community will count against the creator’s FirstClass disk quota.

When a user posts a page, post or comment to an OTSW community, that content is displayed as an outgoing message to the users’s My Shared Documents conference in their mailbox. This is confusing.

In terms of interoperability with our blog and wiki tools, there are three standard ways to connect tools to each other on the web: links, RSS feeds of recent updates and embedding.

OTSW communities do not provide any RSS feeds. Links to OTSW communities, pages or posts, will fail if the user is not currently logged in to the OTSW communities in their browser. Following a link to an OTSW community while not logged in will drop a user into their OTSW desktop, rather than the target of the link. OTSW communities provide no options for embedding their content in other tools.

Looking at the flip side of this interoperability, bringing external tools into OTSW provides a somewhat better picture. OTSW supports regular web links in all posts, pages and comments. OTSW supports attaching any kind of document to a wiki page (e.g. a movie or audio file, or Word document).

OTSW does not provide any facility for subscribing to RSS feeds from other tools.

OTSW does provide some support for embedding external content in OTSW pages, posts and comments. These embeds are performed by pasting arbitrary HTML into the OTSW content embedding dialog. Unlike WordPress, which provides some filtering, OTSW will allow anything to be embedded — and, in fact, embeds most objects as IFRAMES (which allows the embedded site unlimited access to OTSW — not great for security).

One oddity of OTSW embedding is that embedded content is masked by the OTSW embed logo, which must be clicked upon to reveal the embedded content (perhaps as a security measure?). Once the logo is removed to reveal the embedded content (which must be done each time the page is loaded, for each embedded piece of content), the embedded content is presented in an IFRAME exactly the same size as the previously masking logo. The logo is smaller than the standard YouTube video, for size comparison. This means that all embedded content is viewed through what amounts to a porthole.

One possible way around the lack of ability to access an external site’s RSS feed (for example, a feed of recently updated instructional videos from YouTube), would be to use a third party tool such as WebRSS to generate a “badge” which could then be embedded in OTSW.

Considering OTSW’s interoperability with other tools:

  • FirstClass: Rube Goldberg-like dependency on community conferences to remain on the desktop, no warning about disk quota use for conference creators, confusing display of posted content, flaky invitation system.
  • Web Links: outgoing links from OTSW work fine, incoming links are functionally useless.
  • RSS Feeds: non-existent.
  • Embedding: no options to embed OTSW content elsewhere, very limited ability to embed external content in OTSW, requires manifold click-throughs.

Safety

OTSW provides a very well-secured environment for users, in that it leverages our existing FirstClass userbase to automatically limit access to communities. While I have no clear understanding of the true security capabilities of FirstClass, I note that the FirstClass messaging system was, for many, may years, a de facto standard across education — quick and easy to setup, very reliable, very secure. Nine out of ten dentists use it themselves, etc. OTSW does not seem to waiver from the FirstClass security model. In terms of operational security, OTSW appears to be a seamless layer on top of our existing FirstClass system.

Another aspect of security that is well worth considering in a teaching and learning standpoint are the types of habits promoted by a particular tool. For example, blog servers promote, well, self-promotion and publication, hopefully also critical, analytical engagement with external information sources. Wiki servers tend to promote collaboration, with individual accountability, on large documentation and research projects.

As a Facebook-like communication system, OTSW should, then be viewed as a safe learning environment for social networks and media, where students can learn good habits and social graces. Much of the system works in this manner (as did FirstClass in relation to traditional email), providing the ability to track revisions, flag offensive content, engage in asynchronous discussion, etc.

The one oddball is the profile system (and this may be dependent on system settings). By default, the OTSW user profiles are set to demand more and more and more personal information from each user, reminding the users that their “profile is only X% complete… add your [fill in the blank personal information] to complete your profile.” To my mind, without deeper discussion in the classroom, this type of message promotes a culture of thoughtless exposure, rather than a carefully managed digital footprint.

GeekTool/AppleScript Display of Desktop Picture Info

1
2 years ago
by Seth Battis in ,

So… I am the world’s biggest dork. I don’t dispute it. And when I get stressed out, my inner librarian comes out, and comes out big.

I have a large folder of desktop wallpaper that I rotate through with some regularity (every five minutes or so). They all come from the web. And I project my desktop with some regularity. Which means that I get asked about where my desktop photo comes from pretty often (a few times a week). And I teach about media literacy, intellectual property and citation. Which means that I want to give credit where credit is due.

A few years ago, I started actually adding the URL of the page that I had downloaded an image from as its Finder Get Info comment. And then, in one of the Leopards, Apple started including this metadata in the Spotlight database for all downloaded files, too. Which means that, if I know the name of the image on the desktop right now, I can look up the URL that I got it from. That’s a big if.

I spent a little while last night tinkering, and came up with the following command that gets me the name of the currently displayed desktop wallpaper:

defaults read ~/Library/Preferences/com.apple.desktop | grep 'LastName' | tail -n 1 | grep '[^"]*\.[^"]*' -o

This extracts the final LastName entry out of the com.apple.desktop.plist file and pulls just the file name out of it. Then, because I knew that I actually want the URL that I stored in the Get Info comments field, I extended this to the following:

cd ~/Pictures/Wallpapers/Single\ Display/; defaults read ~/Library/Preferences/com.apple.desktop | grep 'LastName' | tail -n 1 | grep '[^"]*\.[^"]*' -o | xargs mdls -name kMDItemFinderComment | grep 'http[^"]*' -oi

You’ll note that I assumed that all my wallpaper comes from a specific folder (~/Pictures/Wallpapers/Single Display/) — but this information could also be extracted from com.apple.desktop.plist (run the defaults command without the grepping to see what I mean — look for ChangePath). The big breakthrough for me was realizing that I needed to use xargs to extract meaning from the result of my grepping, which was presented to mdls with a newline at the end — xargs then runs mdls on all of the one lines of resulting output.

In the end, I presented the output of each of those shell scripts as overlays on my desktop (using GeekTool) and I wrapped all of this into a little AppleScript that opens the web page from whence my desktop image comes:

do shell script "cd ~/Pictures/Wallpapers/Single\\ Display/; defaults read ~/Library/Preferences/com.apple.desktop | grep 'LastName' | tail -n 1 | grep '[^\"]*\\.[^\"]*' -o | xargs mdls -name kMDItemFinderComment | grep 'http[^\"]*' -oi | xargs open"

The real addition is that I use the xargs to pass the URL to open, which opens the URL in the default browser.

In all of this, it is worth noting that Bwana has been enormously useful. As was this article from O’Reilly on using Spotlight from the command line and this page on the defaults command.

Free-style Online Learning

0
3 years ago
by Seth Battis in

One of my responsibilities at Jewish Day School is to write a weekly “tech tips” column for the online faculty news. This is one such tip.

Even as the end-of-year to-do lists are approaching critical overload, I find that one of the joys of the spring is the contemplation of what I will be working on next year. Not so much in a “next year I’ll do this all differently” kind of snit, but with more of a “year in review” focus: spring and graduation makes me sentimental and reminiscent.

With that in mind, in the past week I have come across two interesting resources both for teaching in general and for thinking about our work as “knowledge workers” in the 21st century (to infinity and beyond!). First, Merlin Mann discusses how we do (or do not) allocate our time and attention to getting our projects done. Thoughtful, provocative and entertaining stuff. Second, Williams College’s Project for Effective Teaching has gone online with a truly exciting, provocative array of professorial reflections and questions around specific aspects of classrooms and teaching and learning. Enjoy!

How, you might ask, do videos like these fall into my hands? I follow-up on the sources of interesting articles that I see. And then on the sources of those sources: I like to find where the ideas are swimming around raw and unfettered. I do this by following a boat-load of interesting “edu-bloggers”, by following (and engaging with) other teachers on Twitter, and by doing a lot of skimming.

PowerPoint makes us D-U-M-Dumb

0
3 years ago
by Seth Battis in

One of my responsibilities at Jewish Day School is to write a weekly “tech tips” column for the online faculty news. This is one such tip.

As we head down the homestretch of May and June, more and more students (and teachers) are experiencing siyyum for their coursework, either as final papers or presentations or projects. Projects and papers are delightfully straight-forward and easy to facilitate and grade… at least, when compared to presentations, which have the added benefit of being a potential exercise in goodwill and patience to sit through.

The first hurdle our students have to get over is the technology itself — bringing together all the disparate elements of their presentation into one place and time. A few years ago, I wrote up a cheat sheet of tips that help to avoid the most common student pitfalls. I have not run into technical problems with student PowerPoints since I started giving them this handout (I kid you not).

In general, a good presentation has to nail not just the content and technology, but also visuals and public speaking. And this is the hardest thing to do right. For adults, even. Experts have started to decry PowerPoint as not just problematic, but actively destructive when it comes to communicating information and especially nuance clearly.

Gen. Stanley A. McChrystal, the leader of American and NATO forces in Afghanistan, was shown a PowerPoint slide in Kabul last summer that was meant to portray the complexity of American military strategy, but looked more like a bowl of spaghetti.

“When we understand that slide, we’ll have won the war,” General McChrystal dryly remarked, one of his advisers recalled, as the room erupted in laughter.

New York Times, April 26, 2010

Shifting the focus from a PowerPoint document to the holistic presentation will further the student’s ability to communicate complex ideas — a key skill in today’s (or any day’s) world. Some further reading that is both informative and motivational on that front:

PowerPoint Tips

1
3 years ago
by Seth Battis in

One of my responsibilities at Jewish Day School is to write a weekly “tech tips” column for the online faculty news. This is one such tip.

Making Things Run Smoothly

  • Make sure that you always insert pictures into your presentation using the Insert Picture command from the Insert menu. Do not copy and paste pictures into your presentation. For arcane reasons, copy and pasting pictures can make your PowerPoint fail to display your pictures on other computers.
  • Keep a folder of all of the pictures and video that you add to your PowerPoint. Just in case you need to re-insert it (for example, if you messed up on following the tip above).
  • Video is not embedded in PowerPoint, pictures are – share Zip files. That is, you can insert pictures into a PowerPoint presentation and send the presentation to someone else and they can see the pictures but you cannot insert video, send the presentation to someone else, and expect them to see the video. PowerPoint creates a link to the video instead. To get around this, if you are going to use video, put your presentation and your video files in a folder together, then insert the video. When you are ready to share your presentation, right-click on the folder and Send To > Compress or Zip Archive and send out the Zip file instead. Your recipient can unzip the archive and will have the presentation and the video.

Making Things Look Pretty

  • Black text on a white background is not traditional by accident. It’s easy to read. Think carefully before trying a novel color combination.
  • One picture per slide lets you show the picture big, in all its glory. Multiple pictures per slide lets you compare pictures. Think about which it is you want to be doing (and remember that postage stamps are hard to see!).
  • Don’t stretch your pictures. You can scale your pictures proportionately by holding down the Shift key when you drag the grab boxes on the corners of the picture. This will make sure that the picture doesn’t get distorted.
  • Use text judiciously. This one is complicated: you don’t want to have too much text on a slide because it will get small and hard to read. You don’t want to put your script on the slide, because then you’ll be reading from the slide, which is deathly dull (unless, maybe, you’re Morgan Freeman). But you do want to present text that will support your arguments and highlight important ideas. And you do want to present quotations that are illuminating. One rule of thumb is the “six by six” rule: no more than six words per bullet point, no more than six bullet points per slide. This is totally artificial and you should violate it as needed… but remember it and what it is really urging: don’t overwhelm your audience with text!
  • Less is more. This is true of almost everything involved in PowerPoint, but particularly when it comes to animation and sound effects. They have a campy appeal, and can sometimes underscore a point you’re trying to make. But you ain’t Spielberg and PowerPoint ain’t ILM, so don’t go trying to put in gratuitous special effects just to make your PowerPoint more appealing. Your research and ideas should be the focus, not your ability to make car crash sound effects.
Go to Top