[Grok-dev] Re: Admin UI name change suggestion
faassen at startifact.com
Fri Oct 5 07:42:08 EDT 2007
Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>> So you're proposing we *throw out* the UI entirely in favor of various
>> URL appendages we need to remember?
> No. I'm proposing that you get to the UI not by saying
> http://localhost:8080/ but by saying http://localhost:8080/introspector.
Okay, I misunderstood then, probably due to the /recreate discussion.
You'd expect a recreate option to be part of the /introspector (or
/devui or whatever) UI.
I'd argue against this option, as I think it's good for beginners to see
the UI the first thing they see, application second. That would avoid
the Zope 2 problem where people need to find out about '/manage'.
>> It depends on what you mean by "getting started", right? It's less
>> work to get a single application installed.
> Please convince me that this *isn't* what 99% of the people starting
> with Grok want and I'll be happy to reconsider my view :).
Many beginners will probably expect the application to be installed.
Others probably won't be surprised that it needs to be installed first.
I agree though that grokproject could pre-install an application. That's
a beginner use case.
>> It's more work to figure out everything else. Lack of a UI will make
>> life harder to get started.
> Assuming people want this UI.
That's more an advanced deployment issue. I'm assuming beginners will be
helped by a UI.
> From my experience from working with newbies, they don't detect the
> "broken" state anyway. They wonder why their new utility isn't showing
> up, or why they get a NotFound. I *always* had to explicitly tell them
> that they had to reinstall applications. When I did so, it made sense to
> them, but they too had to inform themselves about that fact.
The UI should definitely help if this makes this visible. The current
trunk shows broken applications in a different area explictily marked as
broken objects. It didn't used to do this, but we ran into this in the
grok tutorial I gave in august and Uli fixed this.
> I don't think anybody ever intuitively turned to the admin UI for this.
> They were simply refreshing their browser pages, and found that they
> stopped working.
Hm, I wonder whether we can't make a clever default view for broken
objects and/or error message that helps people find out. This is
definitely something that trips up beginners.
>> I don't understand how there are less concepts to grasp. People
>> working with Grok will need to understand object publishing;
> Yes. Eventually. I distinctly remember in the discussions around the
> first prototypes of Grok that object publishing was not the first thing
> people should have to learn
Okay, then I misunderstood you. You're suggesting that the current admin
UI forces people to learn object publishing right away? I don't see that?
>> One wouldn't think they would be confused for long as soon as they go
>> to localhost:8080, right?
> I don't understand this question.
Some people, as you say, are confused they need to install their
application instead of it being for them. Confused, but unlikely to get
*stuck* for long (which would be worse), as they won't be confused for
very long as they'll likely see what they need to do as soon as they go
If we pre-install the application the only thing they'd need to do is
click on the actual application link. That reduces the amount of work
they need tod o, and reduces the chance they'll get stuck to virtually
They may still wonder how to actually deploy this as the root (should
they so desire). That's a deployment use case. For that, we have various
approaches, including WSGI/Paste, a UI option that will allow them to
make an application into the default root, or a different way to start
the server. We'll need to work out which one to pick (or perhaps
multiple ones, one easy for beginners and one easier for sysadmins).
>> Anyway, again, having a way to get an application installed by default
>> would be useful in various circumstances.
> WOuld you agree it made sense that one of those "various circumstances"
> was the default setup that grokproject produced?
Yes. Installed. Not installed as the root, though. :)
>> * make installing multiple applications an "expert" use case only.
> perhaps "expert" was the wrong word, but I certainly think it's more of
> a second-week-with-grok use case than a first-day-with-grok one ;).
>> * generally do a lot of work to figure out all kinds of use cases that
>> we already cover today.
> I think they could still be easily covered.
I'd suggest we take "admin UI is the first thing a beginner should see
if they go to localhost:8080" as a requirement besides "the application
should be pre-installed for a beginner when they use grokproject". It's
not a major issue, but it helps with marketing and it helps with
explorability enough for me to think it's valuable.
More information about the Grok-dev