Re: Scripting Interface Design
Re: Scripting Interface Design
- Subject: Re: Scripting Interface Design
- From: Philip Aker <email@hidden>
- Date: Sat, 23 Jun 2007 03:13:36 -0700
On 2007-06-22, at 10:08:42, Christopher Nebel wrote:
On a related note, Mark Alldritt just put up a very good blog
post on the need for a Scripting Interface Design guru to educate
developers about the technology and help them design scripting
interfaces that don't suck:
http://www.latenightsw.com/blog/?p=32
Well worth a read. (I've already left my own 2c on the subject,
of course.;)
However, Scripting Interface Design now presumes an SDEF, so the
first questions should be about the SDEF schema because that now
defines everything.
Hi Chris,
I think you're confusing design with implementation,
No, not at all.
as was Mark to a lesser degree. [1]
The article's topic immediately perceptible and clear to me. My
remarks address cause. I admit it's requires detailed knowledge to
see the relationship though. So very glad you made it through.
Assuming I'm reading Mark's blog correctly, he's mainly concerned
with the Scripting User Interface (capitals because it's an
important concept), which is just the stuff the user sees -- the
various terms and how they relate to each other.
That was part of my impression. However I feel that the statement:
"It’s about designing a programatic interface for an application that
mirrors the user’s view of the application’s data model and
functionality.", enunciates his quandary more specifically. Here the
topic is instantly multi-disciplinary, multi-cultural, and very
complex for goods that people can touch. Even more so for software
interfaces. Psychology, and industrial design come to mind. To give a
hardware example, the iPod, where the classic "less is more" approach
has given Apple a success story, has a huge amount of thought and re-
working put into its design.
We have to go a step further and abstract things into a Scripting
Interface…
The actual implementation could use an aete, or suite definitions,
or an sdef. [2] Yes, we want people to use an sdef, and there are
various things that are easier to express in an sdef, but the point
is that for pure design purposes, it doesn't matter.
Yes, I understand that fully. But sdef is the big daddy now so it's
the obvious vehicle to convey my comments. Tweaking the aete resource
definition at this stage seems an unlikely possibility.
That said, your suggestions have merit.
Thanks very much. I'm truly concerned about a few aspects since I
have gone quite a few steps into a CoreFoundation parser and spent
some time on an XML schema for them.
Just to repeat...
1.
One might very well ask: "What schema?", because it's only a DTD
right now. As such, there's a couple of loose ends that should be
tied up because DTDs permit stuff that's illegal in XML Schema and
there's a problem with that in sdef.dtd. The effect of dealing
with seemingly insignificant details like this can have a ripple
effect upwards on communicating scripting design. That's because
having an XML Schema will enforce the description to an
unambiguous mechanical sensibility.
2.
Does that sound like a limitation? Well no, not for AppleScript.
It will actually be an enhancement. Take a look at the XML Schema
data types <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
#built-in-datatypes>, and regular expression possibilities <http://
www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs> for starters.
3.
When a language can be expressed like that, it follows that the
ensuing implementation, and the possibilities it presents are
clear. Hence explaining scripting interface design will not be
limited to the realm of the guru, but rather more the territory of
advanced users. That is how it should be because it increases the
chances that dictionary designs will be harshly critiqued and from
that, better guidelines evolved.
There are two major points here: one is beefing up the schema
(lowercase, since I'm not speaking specifically of XML-Schema;
there are other possibilities); two is the general role of
mechanical guideline enforcement.
For the first, it depends somewhat on what you think the role of
the schema is
I think the role of an sdef schema is to define the language
unambiguously (paragraph 1 : last sentence, paragraph 3 : first
sentence) and do so at the international standard level of our time.
From that follows many things, including what Hamish Sanderson
picked up on immediately, IDL.
-- should it define *all* allowable behavior, or should you
delegate some of it to other external tools? Since the point here
is to make good design easier (and perhaps bad design harder), then
some sort of automatic enforcement would be useful. I'm fully in
favor of this -- I have several bugs to that effect -- but that
enforcement doesn't necessarily have to be in the schema itself.
Well, maybe you can't speak about the alternates right now, but I'd
just like to say that XML Schema is the international standard for
good reason. And one of my principal concerns is that Apple won't get
duped into using something like Relax-NG or Schematron. Not because
they're not good, but because XML-Schema is more appropriate for a
language definition. It's also the harder, but not unattainable
possibility with a tweaked sdef. I'm prepared to elaborate at length
on the merits of XML Schema for this purpose.
You could easily imagine a tool, maybe a variant of sdp, that runs
as part of the Xcode build system and spits out warnings about
things you're doing that seem fishy.
Easily is correct. I have a non-validating tool, sdmerge, which does
something sdp can't do right now used in an Xcode build phase. I
decided to forego any validation because I figured you'd be upgrading
both sdp and the schema anyway.
In fact, such a tool has to exist for complete coverage, since
there are some sdef constraints that XML-Schema can't express, such
as the requirement that codes and terms have a one-to-one
correspondence.
Perhaps you can elaborate? I think what you want is an attribute
group (use="required") but maybe you're talking about something else.
For the second, it's important to consider what mechanical
enforcement can do for you and what it can't. Some simple
guidelines, such as the NoInterCaps rule, are checkable, as are
certain mistakes which will cause your implementation to break,
such as code/term mismatches. This is good as far as it goes, but
that sort of thing isn't what makes scripting UI design hard.
(Tedious, maybe, but not hard.) What makes it hard -- and this was
Mark's main point -- is making sure that your scripting interface
(that is, the object hierarchy and all the commands) makes sense to
a normal user of your application, and a machine is never going to
be able to check that for you. [3]
See "However I feel that the statement:" above. :-). I really do get
his point. I've considered things like this in depth (prompted by
copious and meaningful comments from day job QA folks).
To sum up: more machine enforcement, great, but it can't solve any
of the hard design problems, so you still need human involvement.
Beside the gory details though, there's also the question of what
the SDEF DTD->schema doesn't have defined. Like extensibility,
adaptability for other implementations, and annotations (appinfo
in particular). And this last bit should be of some concern for
all those dealing with an AppleScript implementation in their
applications because having it be extensible with room for custom
calls will make things very flexible.
We should discuss this in more detail (though probably not here,
it's not germane to the list),
I will copy this reply to scrimps and continue it there. But I'd
certainly like to invite folks over there and participate if so
inclined.
but assuming I understand what you're asking for, I regard this as
something of a non-issue. First, as long as it's conforming XML,
you can add whatever you like, and none of the other consumers in
the system (the dictionary viewer, Cocoa Scripting, sdp) will even
notice -- none of them validate their input precisely because we
wanted people to be able to do that.
Ok that's real good to know.
Second, if you *do* want to be able to validate your sdef (say,
using "xmllint --valid"), you can do that now by adding an internal
DTD subset -- I've done this myself for some projects. Now, it's
true that certain types of extensions are a pain, because the main
DTD doesn't define any particular hooks, so it would be nice to
have something analogous to what docbook [4] has. However, adding
that rests on the assumption that a significant number of
developers actually wanted to extend their sdefs, and so far, none
of them are even using all the features that already exist.
I don't know the docbook specifics but what I mean is a formally
defined extension element for the schema that would be _passed back_
to the application for implementation (via appinfo). One that doesn't
require a Cocoa API (but could if that was your only language
choice). Schematron for instance works via appinfo. This is much
better than having to use <?processing-instruction xxx?>. You might
be able to test with a <comparison-operator … > element that while
defined as an extension, would magically make it back into an aete
because the appinfo would indicate something like: <implementation …
aete-compat="yes" … />
Philip Aker
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden