Namespace paradigm and lexicon

Hi,

I'm trying to come up with an "intuitive" model for presenting namespace concepts to "casual"/non-tech-savvy users.

E.g., MS adopted the terminology of "folders" instead of "subdirectories" in explaining the hierarchical filesystem (which is really just a namespace) of the PC. Then, "typed" objects therein by means of adding meaning to arbitrary "three letter" extensions to those (file)names, etc.

But, this skirts the formal issue of namespaces, in general. And, leaves folks with the misconception that things are "files", etc. (instead of "named objects referenced within a namespace").

I would like to come up with a "friendly" analogy by which users could embrace the concept of different namespaces without clumsy terms and "forced" analogies. I.e., something that recognizes the difference between "name/identifier" and "object" to which it refers.

Note that this is particularly important when you deal with disjoint namespaces in which the underlying implementation need not be exposed to the user (as it probably offers nothing of value in that understanding).

E.g., you name our *dog* without concern for the names of your neighbors' pets, your children, vehicle(s), food recipes, titles of novels you may have authored, etc.

[sorry, I realize this is a bit abstract...]
Reply to
Don Y
Loading thread data ...

Actually I was going along quite well with your discussion until you came to the statement that the name is different than the object to which it refers -- I think you're mixing concepts (there's a bit in "Through the looking glass" where some character says "I _am_ , but my _name_ is , and people _call_ me " -- that would be a good example).

I think your "namespace" example is a good one: at home I'm "Tim", but when I'm working for someone I'm "Tim Wescott" -- the family name qualifier is unnecessary at home, but becomes necessary to distinguish me from the other "Tims" if I'm in a larger establishment.

--
www.wescottdesign.com
Reply to
Tim Wescott

How about comparing it to a fully qualified national telephone number ? (I'm looking at it from a UK viewpoint here in case it matters.)

The namespace identifier could be the area code.

The individual objects could be the telephone numbers within the area code.

Different objects can be called the same thing within different area codes, but it's the area code which resolves the ambiguity.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

e
o
.

"Her name was McGill, she called herself Lil, but everyone knew her as Nancy"

People don't read anymore, they use hieroglyphics. Not just with icons/ folders on a computer screen, but elsewhere. You order a taco, the counter-monkey pushes a pic of a taco on the register. Safe to cross the street? There's a silhouette of a person walking. Of course, not all of this is due to poor education, it can help - particulalry in public - with foreign language speakers.

That said,, files just emerged from the office environment with which most 'western' folks are familiar. A Dewy Decimal System might be made to work or the type of hierarchy used for headers, paragraphs, sub- paragraphs etc. You know, Roman numeral/capital letter/lower-case letter/number/number with lower-case (w'ever)

But I think you may still need something graphical. Like pockets in pants, shirts, overalls, suits and a tuxedo. Or something more universal/without ethnic bias, maybe - like a left fist and a right fist, with something in the palm and under each fingernail? lol!

interesting question - sorry I kinda rambled hah!

Reply to
1 Lucky Texan

"What's in a name? That which we call a rose by any other name would smell as sweet" -- Romeo and Juliet (II, ii, 1-2)

It depends on how philosophical - or how technical - you want to get. Whether physical or conceptual, a thing definitely is not the same as its name. The name is itself a thing, but not the same thing as the thing it names. It's also the case that a thing may have multiple names.

However, the degree to which a thing can be shown to stand apart from its name varies. Naming a thing directs thought or attention to it. A physical object can be indicated without naming it - e.g., by pointing to it - so it is trivial to show that the object is not it's name.

It's can be more difficult to indicate an idea without naming it - it depends on how abstract the idea.

[Kasuf gestures towards his village] Jackson : "He's inviting us to go with him." Kawalsky: How can you be so sure? Jackson : "Because" ... [repeats Kasuf's gesture] ... "he's inviting us to go with him."

An idea may be demonstrated or described, but either can become very complicated. Lacking a sufficiently simple demonstration or description, the only real way to indicate an idea is by name - e.g., "Special Relativity". But still the name of the idea is a separate thing from the idea itself.

YMMV, George

Reply to
George Neuner
[elided]
[elided]

If your users cannot immediately grasp the distinction between an object and its name, then IMHO, they are too stupid to be allowed to use computers, or else too young...

--------------------------------------- Posted through

formatting link

Reply to
RCIngham

Call me cynical (or weird), but given the number of cultures in the world today, I don't think you could come up with anything -- particularly anything involving the hands -- that isn't a rude gesture _somewhere_.

There was a headline in the paper yesterday, about the University of Oregon sports program. Apparently the "cheer gesture" that someone innocently came up with means "vagina" in American Sign Language (or maybe they were jealous of the Oregon State University "Beavers").

So it can happen any where, any time.

--
www.wescottdesign.com
Reply to
Tim Wescott

"Twenty-nine players on the team are enrolled in the university's American Sign Language program."

Innocently came up with?

Hey, I've got some magic beans here ... ;-)

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Hi Tim,

[stuph elided]

I think that recognition that the name is NOT the same as the thing is necessary for people to be able to relate to the concepts of namespaces. For example, "Daddy" means (i.e., refers to) different things in different namespaces. And, "Daddy", "Tim", "Tim Wescott", etc. may be one, two or three different things -- depending on the namespace in which they are invoked.

This is a no-brainer. Drawing attention to it is more confusing than "it" is, itself. :-/

However, coming up with a simple, intuitive way of wrapping these concepts in some friendly "jargon" is the hard part.

E.g., if the namespace supports concepts like "link" and "unlink" (from a classical fileystem based namespace), how do you describe (to a casual, non-technical user) "creating an alias" for an object? What verb describes "uncreating" that alias?

How do you formalize the concept that a name might change based on namespace? I.e., "Daddy" (assuming you are a father) vs. "Tim" vs. "Mr. Wescott" vs. "Brother" (assuming you have siblings) vs. ...

How do you formalize the concept that only certain *parts* of some "other" namespace might be visible within some *other* namespace?

How do you formalize the concepts that namespaces might be completely disjoint? (esp when trying to explain this to someone with a limited exposure to a "unified" namespace -- e.g., a PC filesystem)?

[If you think about each of these, they "make perfect sense". Even if you disregard implementation details. But, how do you come up with a lexicon/model that lets you present these concepts to Joe Hughzer without gobs of explanatory text? -- Remember, I'm talking about ALL names and ALL (types of) objects... not just "people"]
Reply to
Don Y

The guys who come up with these things have probably done more to DECREASE productivity than the person who designed the QWERTY layout! I've got buttons in one of my applications with images of HELICOPTERS on them!! Jeez...

Names shouldn't need to rely on images. E.g., imagine a telephone directory with pictures of everyone instead of their names... :-/ (would it be sorted by hair color? height? :> )

In all seriousness... coming up with names/scheme is the essence of the problem. Further economies beyond that are a separate issue.

Reply to
Don Y

I think that's too hard for folks to distinguish from the "number" itself. I.e., it just looks like "a few more digits".

And, those namespaces are interrelated (interconnected?). A better (dubious) example might be the telephone numbers in the US/UK/wherever vs. the phone numbers in Barbie's Playhouse (i.e., they have no relation to each other and calls can NEVER be routed between them).

I'm having a hard time coming up with examples to illustrate these fundamentals.

E.g., I can have a namespace called "Friends". The names (identifiers) within it refer to people that I consider "friends/acquaintances". I can have another namespace called "books". The names therein refer to publications. I.e., you wouldn't expect to find a "friend" listed among the "books".

[Again, this is one of those, "D'uh..." concepts.]

However, people used to *unified* namespaces -- e.g., files on a PC -- would EXPECT *all* of these objects to exist in *some* shared/common/unified namespace. E.g., "BobJones.friend" and "DoAndroidsDreamOfElectricSheep.book". They might reside in different parts of that (hierarchical) filesystem (e.g., ".../Books/" and ".../Friends/") *or*, could be lumped together in some particular spot (e.g., "../ThingsForDon/")

I'm saying that this unifying namespace (like your "Global Telephone Nework Numbering System") need not exist (or, might not be visible to the user).

E.g., imagine if a PC application's "Open File" dialog didn't have a "Browse" button (or other way of "changing directory/folder). I.e., what you see in the folder that the application presents to you in that dialog is *the* namespace -- even though you know/suspect that it is existing in some other, larger/unifying namespace!

(this is what others me about the telco analogy)

Reply to
Don Y

How many have observed that "My Documents" maps to "Documents and Settings\Don\My Documents" when "Don" is logged in and "Documents and Settings\Bob\My Documents" when "Bob" is logged in?

How many have observed that "My Documents" maps to "Documents and Settings\Don\My Documents" *for* Don CONCURRENTLY with mapping to "Documents and Settings\Bob\My Documents" for Bob??

Could *any* of them create *another* arbitrary name to represent some particular object at some other place in the filesystem (namespace)?

How would they come to grips with "DELETE MYFILE" if MYFILE referenced a mutiply-linked object (i.e., would they understand that DELETE is atually UNLINK-ing the MYFILE name from the object to which it refers? Or, would they expect the actual object to be REMOVED from the storage medium?)

How many would recognize that ".../now" is "12:52:05" but "12:52:08" just 3 second hence? How many would be puzzled to NOT find an actual *file* on the disk having that name, ANYWHERE?

How many would understand ".../local/date" and ".../french/date" of "22 January 2011" and "2011 Janvier 22" to be the *same* object (simply accessed via different namespaces)?

How many of them would understand the idea of mounting a namespace

*at*/over/alongside some other portion of the namespace? I.e., that ".../FriendsAndFamily/" can be the *union* of ".../Friends/" and ".../Family/"? So, changes to ".../Friends/" are *instantly* reflected in ".../FriendsAndFamily/" (though changes to ".../FriendsAndFamily/" can not reflect back to *either* of the sourcing namespaces!)

And, how would they relate to deleting a name *from* the ".../FriendsAndFamily/" namespace? (e.g., "Mom") Would they also expect it to disappear from the counterpart namespace (i.e., ".../Family/Mom")?

I suspect most of these concepts would leave MOST casual computer users puzzled. IMO, you have to be able to conceptually separate the names from the objects in order to embrace these sorts of mechanisms. I imagine most users do NOT do so (at *any* level of formality)

Reply to
Don Y

"Names" and "things" are not the same. Every "thing" has at least one "name", if you are going to be able to make use of it - but "things" often have several "names". For example, in real file systems (rather than MS's toy filesystems) files can have lots of names - any number of directory entries, which are "names", can point to the same inode, which represents the file or "thing". And each name is equally valid. In programming, you can have multiple pointers or references object.

So while it sometimes makes sense to think of "things" as having a single canonical identifier or "name" (such as the inode number of a file, or the address of a programming object), sometimes multiple names are often important.

Reply to
David Brown

Exactly. The key, here, is that a name *is* a "thing" (which brings up how to name a *name*! :> ). You can change a name without changing the thing that it names. Likewise, you can change the named *thing* without changing the *name* (e.g., "employer" can point to different objects, over time).

The probem that I forsee is that exposure to PC's has led people to simplify their understanding of names and objects. I.e., a file's

*name* is synonomous (in many people's minds) with the file itself. People talk about a "spreadsheet" or a "document" and treat the name of the spreadsheet/document *as* the spreadsheet/document.

While they never give a second thought to *changing* the name of that spreadsheet/document, they still see the *new* name as synonomous with the named object itself.

Since name scan refer to abstractions or concepts (or "relations"), separating the "name" from the "object" (implementation) seems essential.

The PC model leaves people with the expectation that an "object" is static unless *they* ct on it. I.e., everything *should* remain unchanged while the machine is "off". So, the notion that a "named thing" (e.g., ".../today") can change without any deliberate action by the user isn't something folks expect (because they think of a tangible "thing" -- magnetic domains on a disk platter -- behind each "name")

Reply to
Don Y

Op Mon, 21 Nov 2011 22:10:24 +0100 schreef Don Y :

I assume that you are talking about a system that has a name resolver that sometimes needs to tell the user that the specified name cannot be resolved. In that case guess you could say that a namespace is a piece of context by which the system can remove ambiguity about what the user means.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
 Click to see the full signature
Reply to
Boudewijn Dijkstra

At least QWERTY had a purpose. The old mechanical typewriters couldn't keep up with the typists ... they kept jamming. So the keyboard was modified to separate the most common (English) letter sequences.

George

Reply to
George Neuner

ame

t
e

is

d
A

age]

."

Some of what you mentioned has to do with expectations. I recall, when 'block programming' of on our local Public radio went away. Seems the new producer decided, "when people tune into a radio station, they want to know what will be playing" (as in, the country station, the classical station, etc.) Yet, television does just fine with block programmin g. The difference seems to be , access to a schedule. Radio schedule still sems like an odd phrase. (of course, this was a long time ago)

And, consider the ease with which displayed data can change nowadays. That is fairly recent. If I pick up a book titled "Moby Dick" today, and pick it up again next week, it's likely it will contain and 'display' the same data as before.(that is, no one erased and re-typed any of the pages inside). But that is not true for my wife's Kindle. It isn't a book, it's a reprogrammable storage and display device. It's always a Kindle, but that is about the only thing that will be constant.

But, where I work, we have files containg info on customized product for specific customers that may change, yet the contents still 'relate' to the files label. The label doesn't change.

And then there is the problem of recursion. If a library should create a book, listing all the books it contains, should it also include the master list book - in the master list book?

Again, I think I rambled. But the subject is somewhat difficult for me to pin down I think.

I'll leave you guys to it.

Reply to
1 Lucky Texan

echo "This is the contents of file 'thisfile.txt'" > thisfile.txt mv thisfile.txt thatfile cat thatfile

--------------------------------------- Posted through

formatting link

Reply to
RCIngham

Yes -- perhaps my reference to (deliberately) "DECREASE productivity" was too subtle ;-) The "icon-ography" reeks of similar intent :-(

Reply to
Don Y

Of course! But, those expectations are a consequence of being "conditioned" to a particular "model" (for the object(s) in question). My contention is that the desktop computer (et al.) have simplified the concept of files, directories, etc. to a point that people don't recognize the distinction between the name (concept) and the item ("file").

What I'm trying to do (asking here) is come up with a simple analogy/model that highlights the difference between a name and an object; and, between names in namespaces.

The idea is so "basic" that it is hard to draw attention to it without baffling people: "Huh? What' he talking about?" *or*, leaving people wondering what the "meat" of the issue is (since they take the issue so much "for granted" that they wonder if there isn't some subtlety that they are missing: "Why is he spending so much effort on something that I *think* is fairly obvious?")

But, again, this is so *fundamental* that you (and your peers) never even *think* to question it. And, if someone wrote a paragraph or two explaining this, you'd scratch your head wondering: "Of

*course* the contents will change. Why is he drawing so much attention to this? Is there some OTHER case where the contents DON'T CHANGE???"

It's akin to the commercial in which someone is asked to describe the taste of "milk". After fumbling for a while, they are handed a glass of some and asked to describe the taste: "Tastes like milk!"

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.