As I said I'm not a fan of neither forms in modal panels, or multi-page forms.
Main issue I have with modal panels are they are not bookmarkable and are more size
constrained. For example someone that often creates applications could just open:
http://www.keycloak.org/saas/create/application
Multi-page forms are not very nice as you don't get the whole picture, and there's
no need for these with JS-style applications as the forms can be dynamic.
When a user doesn't have any realms or applications yet, I think there should be a
single "Create your first application" button, there's not even any need for
an applications or realms tab in the menu. This takes you to the create application page.
Which is a single form with sections like (each section should be collapsable, where I
show - it's shown by default, and + it's hidden by default):
<application options> [-]
<advanced application options> [+]
<realm options> [-]
<advanced realm options> [+]
When a user has created the first application + realm the next time the user creates an
application the <realm options> section would allow the user to select an existing
realm, or create a new one (again the new realm can be created from the same page).
For forms I think we should store which sections a developer has expanded in html5
localstorage so that next time the user visits this page it would be expanded. This also
applies to viewing applications/realms. For example if a user when created an application
expanded the advanced application options section, this will be expanded in the future
when the user creates a new app or views an existing app.
Also we can do things like saving the sate of unsaved forms to localstorage. For example
if a developer was creating an app and the browser crashed, or he had to go a way for a
while, the form was saved to localstorage while he was updating it so he could just go
back to
http://www.keycloak.org/saas/create/application and whatever details he put in
last time was there again.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Monday, 12 August, 2013 8:13:53 PM
Subject: Re: [keycloak-dev] Admin UI
I'll state again, that I don't like this flow. What you have right now
is too complicated IMO. The concept of a realm is not difficult to
understand. We want and need the user to understand the concept of a
Realm and how an Application fits in a Realm. Anything beyond the
simple case they will have to understand this relationship. Enterprise
Java users will already understand this concept. Any admin that has
managed security before will also understand it. As it is, developers
will want to use keycloak for two main reasons: Social broker and/or
Single-sign-on for multiple apps. Whenever the user wants to manage
multiple web site under one login, the concept of a Realm will be required.
IMO, have a "Getting Started" Wizard if you want to make it simple for
1st time users. After registration bring up the admin UI, have 2 large
buttons within the main screen "GETTING STARTED" and "ADVANCED
SETUP"
Getting started walks you through a wizard, baby steps, explaining each
part. Last few steps show screen shots and point out things about UI.
Explain what a realm is, etc...
GETTING STARTED WIZARD (each step is a different page)
1. Do you want social login? (Explain it)
2. Do you want a registration page? (For non-social logins)
3. Require SSL for all interactions?
4. What is the name of your Application?
5. What is the base URL of your Application?
6. What is your login session timeout?
7. Next you must define the Realm your application will run in. A realm
manages your users and one or more web sites or web services. You can
have your Realm manage multiple web sites and have single-sign-on
between all these sites. What is the name of your Realm? (default to
Application name) (FINISH)
8. Do you want to create a test user?
9. Username password (FINISH)
10. You are now brought to main Admin UI. Role creation, OAuth Client
creation, role mappings are all hidden by "Advanced settings" links.
The page you are brought to is Application Server Setup. Which has links
for "Configure for JBoss" "Configure for RAILs", "Configure for
Tomcat"
etc...
We could even have a wizard that babystep's you through each new feature
that could be shut off. For example, if they clicked on "Advanced
Configuration" link on the menu and then clicked "Add Role" a simple
Wizard would pop up with an opt-out option like ("Do not show this
wizard again".
The website would also have links to video tutorials and example
applications.
On 8/12/2013 1:31 PM, Gabriel Cardoso wrote:
> Hi guys,
>
> here is the link for the Admin UI screens:
>
https://gatein.mybalsamiq.com/projects/keycloak/grid. Please read the
> annotations in red in the pages.
>
> - The first scenario (create the first app) goes from the screen /Create
> first application/ to /Overview with application/. We talked about this,
> the concept of realm is hidden for the user here.
>
> - The second scenario (create second application and import data from
> another application - aka create realm) goes from /Overview with
> application/ to /Overview realms application/. This is important because
> the user still does not know that he can share info between apps. The
> wizard will be probably only used at this time and in the next time the
> user will probably want to create an application directly inside a realm.
>
> - The third scenario (create application and link it to a realm) goes
> from /Overview realms application/ to /Application realm users/ . I
> guess this will not be often used, since the user already knows the
> concept of a realm and will probably create a new app inside it. But we
> should allow different task flows. Lower priority I'd say...
>
> - The fourth scenario (create a realm and create an application in it)
> goes from /Realm creation modal overview/ to /Realm settings after
> associating app/. It seems that this will be the flow for enterprise
> users after the second application. I guess this is the flow that Bill
> was thinking about.
>
> I await comments on both the scenarios as on the flows and page details.
>
> Thanks,
> Gabriel
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev