[Grok-dev] Re: Admin UI name change suggestion

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
[snip]
>> 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'.

[snip]
>> 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.

[snip]
>  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?

[snip]
>> 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 
to http://localhost:8080.

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 
nothing.

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. :)

[snip]
>> * 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 ;).

Sure. :)

>> * 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.

Regards,

Martijn