Internet at last!
It's taken 39 days, since moving from my old place, to get internet access up and running at my new place. One of the reasons I haven't written to this blog much lately.
building and refining my views
It's taken 39 days, since moving from my old place, to get internet access up and running at my new place. One of the reasons I haven't written to this blog much lately.
Posted by
James
at
11:07 pm
0
comments
Labels: biographical
MIT Technology Review reports
Engineers at the University of Texas at Austin have patented a laser microscalpel that allows a surgeon to operate on tissue one cell at a time, precisely targeting disease while leaving healthy surrounding cells alive.Current technologies for destroying a cell damage surrounding cells. The device also provides imagery of the cells -- using two-photon fluorescence microscopy -- to guide the surgery.
A problem that remains to be solved before the device can be used on patients is shrinking the width of the probe from 15 to 5 millimeters--the size of the standard tools used in endoscopic surgery--so that it will be compatible with existing surgical technology.The research was published in the June 23 issue of Optics Express.
Posted by
James
at
4:57 pm
0
comments
Labels: miscDevelopmentsAndAdvances
1 in 4 people of European descent carry a gene that leads them to feel famished more often -- leading to a greater risk of obesity -- researchers have found. The gene has a significant impact on the production of several hormones controlling our appetite. The research was undertaken by an international team led by Imperial College London, and has been published in Nature Genetics.
Posted by
James
at
4:38 pm
0
comments
Labels: miscDevelopmentsAndAdvances
Integrating medical devices in hospitals could help save lives. This article from MIT Technology Review gives a few examples of efforts underway to do this.
Posted by
James
at
4:26 pm
0
comments
Labels: miscDevelopmentsAndAdvances
Here's a neat idea for a train that trains wouldn't have to ever stop at stations. It's been developed by Taiwanese inventor Peng Yu-Lun. (via Carectomy).
On the top of the train sits a little car, and passengers wanting to get off the train can enter it before it reaches the next station. As the train drives through the station, the car slides off the top of the train and onto a railing beside the platform.
Passengers wanting to board the train get into a similar car at the platform before the train arrives, and it slides onto the train as it passes. So at each station, the car currently on the train slides off and a new one slides onto it.
The video on the linked page shows how it works.
Posted by
James
at
6:48 pm
0
comments
Labels: miscDevelopmentsAndAdvances
People's use of cut and paste operations is driven by the moment-to-moment way they are perceiving and thinking about tasks they are trying to perform.
I'll try and explain what I mean by talking about the last two examples I've given.
In the second example, the person wanted to copy a bibliographical entry, containing both the entry's text and, from within that, the URL of a link (to an online copy of the paper).
In the way they're looking the task, they conceptualise the paper as a single thing that they want to note down information about. And thus it's desirable to be able to perform a copy operation on the text, immediately followed by a copy operation on the URL.
Then they've got the information they want about the paper, and can now switch to their notes file and paste it.
Having to copy the text, switch to the notes file, paste it, switch back to the bibliography, copy the URL, switch to the notes file and then paste that is a distraction that doesn't mesh so well with how the person is perceiving the task.
In the first example's scenario, there's really two ways that the person could be perceiving and thinking about their task as they go about it. In the way I presented it, the person wants to grab a bunch of server names from a diagnostics report, then open an email and paste them into it. That is, they're thinking of it as a batch-copying operation like with the bibliographical entries.
Alternatively, they may approach the task in a more serial fashion, scanning through the diagnostics report, finding a particular server that they want to investigate, thinking a bit about the problem, copying that one across to the email and adding a short write up for it there, and then going back to the report and repeating the process to find the next server of interest.
Whether the person undertakes the task in a 'batch' or 'serial' fashion may depend on factors like the size of the report (how many servers, how many statistics about each of them), the nature of the problems with the servers, whether they basically already knew which servers were problematic before looking at the report, etc - and also on the person's habits and nature.
The general point I'm trying to make is that cut and paste it not just about "moving information around". It's about supporting the ways the user wants to move the information around, in the context of how they perceive and think about the task.
When someone is performing a task, they've got some notion of their goal in mind (though it might be very vague). The information in front of them, and how they perceive and think about it, will shape how they will want to proceed.
Within this context, they decide on the sorts of operations they'd like to perform. While they are performing them, they need to be able to keep in mind (though it doesn't have to be fully consciously) what their broader goals are, what tasks they want to do next (we often have in mind the next few things to do), and often something of the state of things before performing the operation.
In their minds they break down the task in a certain way, and the operations provided by the software should try and mesh with this breakdown. That is, offer ways to perform each of those tasks in a convenient fashion.
It's easy to look at operations -- like cut and paste operations -- in the abstract, and think, well if I can already achieve the same effect one way, why do I need another way of doing it? The answer to that is that the other way may better mesh with the way you are perceiving and breaking up the task.
Posted by
James
at
6:25 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
My last example was of batch-copying items from a report to an email. Here's another batch-copying example.
A person finds an online bibliography of papers on an AI topic they're researching, and wants to note down, in a file in their text editor, several of the papers mentioned. Some of the bibliographical entries link to online copies of the papers. They want to note down both the text of the entry and the link (if present).
With a single-item clipboard, noting down the details of a paper would mean copying the text describing it, switching back to the bibliography and then copying the link's URL.
It'd be much simpler if you could copy both those things to the clipboard first, and then switch to the text file. And even better if you could copy those details for all of the papers first, then switch to the text file and paste them all.
Lets look at how much difference it'd make if the person wanted to note down 15 of the papers. Using a single-item clipboard, it'd take 8 operations to copy the details for each paper (and 7 for the last one):
1) copy text of entry
2) switch to text file
3) paste text
4) switch to bibliography
5) copy url
6) switch to text file
7) paste url
8) switch from text file to bibliography
(that last step isn't required for the last paper you copy)
So the formula for the number of operations for N papers, with a single-item clipboard, is:
((N - 1) * 8) + 7
if N is 15, that's 119 operations
With a multi-item clipboard, you'd need two copy operations per paper, two paste operations per paper, and one switch from the bibliography to the text file:
(N * 4) + 1
for an N of 15, that's 61 operations -- 58 less and almost half the number.
Posted by
James
at
4:42 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
You can copy the URL of a link on a web-page by right-clicking on it and choosing the 'Copy Link Location' (or whatever it is called in your browser) option on the context-menu.
How could you use mult-item clipboard operations for items you copy via menu items, such as in this case? How could you specify where in the clipboard to copy it to, and whether to insert it as a new item there or to replace the existing item there?
Here's how it could work. To insert the URL as the third item in the clipboard, the user could type
ctrl(+shift) 3 +
and then while still holding down ctrl,
right-click the link and click 'Copy Link Location'
which is essentially the same set of keystrokes as you'd use for performing the same copy operation with some selected text. The difference being that here they don't type the 'c' as they would to copy some text.
Posted by
James
at
1:12 pm
3
comments
Labels: computing, thoughts, xCutAndPaste
If you want to transfer a batch of items from one context to another, a mult-item clipboard means you don't have to switch back and forth between the two contexts to copy each item.
A computer-network admin might be looking at a network-diagnostics report and want to pull out the names of some of the servers mentioned to put into an email to a colleague about having a look at them.
The report contains various details and statistics about the company's servers. The information is layed out in a table, and the server names are in a particular column. The admin wants to mention three of those servers in an email, so they copy these to the clipboard, then they open an email and paste them into that.
With a single-item clipboard and 3 items to copy, there'd be 5 switches between windows: for the first item, switch to the email and paste it, then for the next two, switching back to the report then back to the email. Whereas with a mult-item clipboard, there'd just be a single switch between windows -- 4 less.
The alternative means to copy the information with a single-item clipboard, would be to select an area of the table that contained the three server names, paste that, then remove all of the extraneous pasted information. It'd depend on the specifics of the situation as to whether this would be quicker or not.
Posted by
James
at
1:10 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
My last post looked at a case where it is useful to have multiple clipboard items. Here's another.
There are multiple terms the user wants to search for within a number of documents, and the editor / word processor only allows them to search for one item at a time.
To make it easier for themselves (and avoid typing errors), the user wants to cut and paste the search terms into the Find dialog box. Within a document they need to individually search for each item, and then they need to repeat this process for each of the other documents.
With a single-item clipboard, each time they wanted to paste an item again (for searching the next document), they'd have to recopy it into the clipboard.
If there were 3 search terms and 5 documents, then you'd have to add each term to the clipboard 5 times. That is, make 5 copy operations. In total, for all 3 terms, you'd have 15 copy operations for loading them into the clipboard. And remember that each of those 15 copy operations would involve finding an existing copy of that term that you'd stored somewhere already.
With a mult-item clipboard, you'd only need to perform 3 copy operations - that's 12 fewer copy operations and 12 fewer times having to find an existing copy of that term to copy.
In my previous example, I considered the case where a person wants to paste a particular phrase a number of times during the course of writing a document, and they need to perform other cut and paste operations in between each of these. In the present example, you want a multi-item clipboard for essentially the same reason - because you're interleaving other cut and pastes between the pastes of a particular item.
It's just that in this case, all of the items are like this - things that you want to paste multiple times over a period of time, with other cut and paste operations interleaved.
Posted by
James
at
2:41 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
I want to start looking at why you'd want some of the features I've described (there are still some more features to describe, but I'll get to them later).
Here's a reason for wanting to be able to store up more than one item on the clipboard.
Sometimes you want to paste the same information multiple times, and it may be some time between each paste.
There might be a certain phrase that will need to be included various times in a document you're writing, which you may end up needing to paste five times.
In a case like this, in between those pastes you'll want to be able to perform other unrelated cut and paste operations.
If you've only got a single-item clipboard, then each time you perform one of those other cut and paste operations, you'll have to recopy that phrase onto the clipboard before you paste it again.
That means you'll have to either find one of the other instances of the phrase in the document, select it, then copy it. Or you'll have to store a copy of that phrase somewhere like in another document just containing it so you can quickly get it from there.
Posted by
James
at
5:22 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
Imagine that the clipboard contained the name of a car part and the identifier for that part
1) black steering wheel
2) sw_bw07
and that the user wants to put them into a destination document with the name followed by the identifier in brackets, like:
black steering wheel (sw_bw07)
Rather than just pasting those items in then adding the brackets around the identifier, you could use a template paste to specify you want to paste the first item followed by a space then the second item enclosed in brackets.
Effectively, you'd enter (where an underscore is used to represent a space)
ctrl(+shift) v t #1_(#2)
the 't' says you want a template paste. Following the 't' is the specification of the template: paste the first item on the clipboard followed by a space, an opening bracket, the second item on the clipboard then a closing bracket.
If you break that up into the individual keystrokes, what the user actually types is
ctrl(+shift) v t # 1 _ ( # 2 )
Because the '#' has a special meaning (used to refer to items on the clipboard), if you wanted to include a literal '#' in the text, you'd have to type '\#'.
With paste commands, if you don't specify a specific position on the clipboard the last position is assumed. So to template paste the item in the last clipboard position with brackets on either side of it, you could type
ctrl(+shift) v t ( # )
That is, you can have an anonymous item reference. It is possible to have multiple anonymous item references. The idea behind how they are parsed is that the further right an item is on the clipboard, the more likely (it's assumed) it is to be more recently entered. And it's assumed you want to fill the '#'s in the template in the order they've been added (that is, from left to right, starting at the position such that the last item in the template is the last item in the clipboard).
So if you had four items on the clipboard and the last two were a part name and a part identifier, and you wanted to paste it like before with the part name followed by a space then the identifier in brackets, you could type
ctrl(+shift) v t # _ ( # )
The rightmost # is taken as referring to the last item on the clipboard, and the next rightmost # the second last item on the clipboard, the third last # the third last item on the board, and so on. Just specifying the '#' items without explicitly specifying the positions is just a shortcut, and what I've outlined is just my current thinking about how that might best work.
What if the template refers to more items than are in the clipboard? The same principle applies. The missing items are still to be filled in, so they are "more recent". That means that if there are three items in the template
ctrl(+shift) v t # , _ # ( # )
but only two in the clipboard
then the third template item is still to be filled on. The second item is taken as the second on the clipboard, and the first the first on the clipboard.
then since there are only two items it'd paste
item1, item2 ()
Handling (the various cases of) anonymous references to clipboard items is really about shortcuts. What I've described is just my current thinking about what'd be the most convenient default behaviour. You'd really need experience with template pastes to see how it was.
I suspect you'd soon enough pick up the way these default cases work. With cut and paste you've got fairly immediate feedback and you can always undo things if it's not what you want.
(You might have picked up that you could implement the functionality of a join paste with a template paste. But I think that the join paste is such a common pattern that it makes sense to have a specific command for it).
Posted by
James
at
1:57 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
A multi-item clipboard is a list of items.
On the one hand, items can be individually added to that list
CTRL(+SHIFT)+C,+
where those items might be taken from different places within the present document, or from within a number of documents.
On the other, multiple items can be added to the list in a single go using a split copy. The items come from a single range of text, which the split copy divides up into individual items, each of which becomes its own item on the clipboard.
It's copying from a list of items in the document to another list of items in the clipboard. These are different types of lists.
The list in the document is an implicit list - the text editor doesn't really know that it exists (it does in some limited ways, like being able to press CTRL+RIGHT_ARROW_KEY to jump to the start of the next word).
The list in the clipboard is an explicit list. Each item is separate, and the operations understand that it's a list of items. The advantage of this is that you can then tell it to paste just the third item, and then later when you need the fourth item, just that.
Both implicit and explicit lists have their own advantages (and disadvantages). Implicit structure allows you to deal with the information in a more fluid way, and explicit structure imposes more rigidity.
Cut-and-paste is for repurposing information, whether for editing what you've got, or for making a new copy of the information in another context. In either case, you're making a copy of the information from a source, and then putting that information back into a destination (which may even be the same place).
It can be useful to take an implicit list and copy it into an explicit list, so then you can repurpose that information as a list of items -- pasting individual items at different times in different contexts, for example.
Split copies allow you to translate between the implicit and explicit.
Posted by
James
at
1:30 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
A document might contain a line of text like
13491, Orange, 2, $50
which can be considered as a sequence of items delimited by ', '.
You could select that text and, with a 'split copy' that specifies the ', ' delimiter, copy each item onto the clipboard as a separate item (in the following, an underscore is used to represent a space):
CTRL(+SHIFT)+C,S,,_
The clipboard would end up containing four items:
1) 13491
2) Orange
3) 2
4) $50
Remember that by default when you copy something to the clipboard it replaces the last item on the clipboard list. When you're copying multiple items on the clipboard with a split copy, the first of those items would replace the item currently at the end of the list, and the other items would be inserted after it.
If there were three space separated words in the document and you wanted to copy them as new items at the end of the clipboard list, following what was already there, you could use '+' to do so (again with a space represented by an underscore):
CTRL(+SHIFT)+C,+,S,_
If you wanted to insert the new items starting at a specific position in the clipboard list, like at position 3:
CTRL(+SHIFT)+C,3,+,S,_
(At this stage I think it should probably be possible for the user to list the position specifier '3' and the '+' in any order - the previous command could also be written as:
CTRL(+SHIFT)+C,+,3,S,_
but this is something I'll come back to).
If you specified a delimiter that wasn't contained in the selected text, I think the most sensible behavior would be for nothing to be copied to the clipboard (perhaps with a subtle auditory or visual indication of the failure). The most obvious alternative would be for the entire selection to be copied as a single item.
Posted by
James
at
8:21 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
Unfortunately image I've uploaded has lost the animation (or somethign like that) - so you'll have to click the picture to see the original images with the 3D effect!
Very cool way of showing 3D depth in images! No doubt would get irritating soon enough, but quite effective. These animated gifs must be made by quickly switching between two stereographic images.
Posted by
James
at
7:16 pm
0
comments
Labels: humourFunInteresting

Looks interesting from the outside. I'd be interesting to know what it seems like when you're standing within it.
Posted by
James
at
8:35 pm
0
comments
Labels: humourFunInteresting
The user could use a 'joining paste' to paste all of the items in the clipboard into the document at once, separated from each other by a specified delimiter. For example:
CTRL(+SHIFT)+V,J,|
to join paste the clipboard contents, seaparated from each other by a pipe '|' symbol. If the clipboard contained the three items 'toyota', 'ford' and 'mitsubishi', that operation would result in
toyota|ford|mitsubishi
The 'J' in the command specifies that you want to 'join' the items. You can follow the 'J' with whatever you want to use as the delimiter. If you don't specify a delimiter, a carriage return would be the default.
The delimiter wouldn't have to be a single character. After typing the 'J' you could press whatever keys you wanted - the command would only be executed when you released the CTRL key. So you could type
CTRL(+SHIFT)+V,J,;<ENTER>
for the delimiter to be a semi-colon followed by a carriage return:
toyota;
ford;
mitsubishi
In the examples I've given, the pasted items would just be left on the clipboard. You could use a pop-paste within the command instead. As with a normal pop-paste, you'd place a minus sign '-' after the 'V':
CTRL(+SHIFT)+V,-,J,;<ENTER>
(So far it's been assumed that you want to paste all of the items on the clipboard. Later we'll look at list ranges, which would be used to only join paste some of the items.)
Posted by
James
at
6:29 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
Similiarly to being able to cut/copy items into any position within the list, the user could paste from any position within the list.
For example, pasting from the last position in the list
CTRL(+SHIFT)+V
that is, ordinary paste.
or pasting from the second item in the list:
CTRL(+SHIFT)+V,2
Those paste operations would leave the pasted item on the clipboard.
A 'pop-paste' would remove the pasted item from the clipboard. You could pop-paste the last item on the clipboard
CTRL(+SHIFT)+V,-
If there were four items on the clipboard and you pop-pasted the second item
CTRL(+SHIFT)+V,2,-
then the items that were originally at the third and fourth positions would be shifted one position to the left, into the second and third positions.
Posted by
James
at
7:56 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
I've described cutting/copying text to a new item at the end of the clipboard list, or to replace the item at the end of the list. The user could also cut/copy text to any position within the list.
For example, copying some text into the third position in the clipboard list:
CTRL(+SHIFT)+C,3
or copying into the first position in the list:
CTRL(+SHIFT)+C,1
I'm counting the first position in the list as '1' not '0'.
You could also insert text as a new item in the list. If the list had three items in it, and you wanted to add a new item into the second position (thus pushing the items originally in the second and third positions to the right one place, into the third and fourth positions), you could type:
CTRL(+SHIFT)+C,2,+
(The reason for making the positions start from 1 is that if you're going to be explicitly specifying list item positions, I think it's likely that most of the time you're going to be dealing with small numbers less than 5. If you start the position with 1, then those 5 numbers are all in a row together on the keyboard. If you started at 0, then the common set of numbers would be separated by a fair gap on the keyboard, which could make things a little less convenient).
What if there were three items on the list, and you told it to add a new item at position 9? I think the most sensible thing for it to do would be to just add a new item at position 9. I don't see a problem with leaving those other clipboard positions empty.
Posted by
James
at
6:42 pm
0
comments
Labels: computing, thoughts, xCutAndPaste
As a note to myself, some of the other things I want to write about:
cutting and copying - inserting an item anywhere in the list
cutting and copying - replacing an item in the list
pasting - removing pasted item (pop paste)
and then getting into why this sort of thing is useful
the same information often needs to occur in multiple places but in different forms
this and other motivations for common cut and paste usage patterns
and the ops support things like using clipboard as a queue or stack, as one way to support those usage patterns
other misc tools/operations such as list ranges, list reversal
splitting and joining cuts-copies-and-pastes
cut-, copy- and paste- templates
relationship between cut and paste and the notion of 'scratchpads'
why the MS office mult-item clipboard sucks
features designed for "expert users"
Posted by
James
at
10:42 pm
0
comments
Labels: computing, thoughts, xCutAndPaste