[keycloak-dev] How to render claim data entry and display?

[Bill Burke]

On 2/23/2015 9:54 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 23, 2015 3:43:11 PM
>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
>>
>>
>>
>> On 2/23/2015 9:13 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, February 23, 2015 2:59:13 PM
>>>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
>>>>
>>>>
>>>>
>>>> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, February 20, 2015 3:15:19 AM
>>>>>> Subject: [keycloak-dev] How to render claim data entry and display?
>>>>>>
>>>>>> I'm not sure how to render claims within the admin console, registration
>>>>>> page, and in the user self service pages.  The thing is that generically
>>>>>> rendering user metadata can look quite ugly.  Address is one example
>>>>>> where the grouping and ordering of each attribute is important to look
>>>>>> nice.  There are other instances where you need to group types of data
>>>>>> together (home phone, fax, work phone, mobile).  Then there is the
>>>>>> problem of what claim data do you show on what pages which is harder
>>>>>> than it seems, for example, registration page might only require a
>>>>>> mobile number, but admin console and user profile page might want to
>>>>>> show home, fax, work too.  You would end up having to define a data
>>>>>> model that captured metadata for each page type (registration, user
>>>>>> profile, and admin console).  Finally, if you have generically rendered
>>>>>> claims, what happens when the user wants to override this rendering and
>>>>>> put their own formatting, .css types, etc. in?
>>>>>>
>>>>>> This leads me to think that we should just punt to the developer.  In
>>>>>> this case, there would be no data model for claim types and everything
>>>>>> would be driven simply off of UserModel.attributes.  Develoeprs would
>>>>>> have to extend the admin console and account themes and we would provide
>>>>>> a template for referencing UserModel.attribute data within Angular HTML
>>>>>> (admin console) or Framemaker (account service, registration page).
>>>>>
>>>>> For registration page and account management I think supporting simple
>>>>> attributes in the default template would be good enough. Users can then
>>>>> extend the templates if they need something more. In the future we can
>>>>> look into creating widgets that can display certain things so users don't
>>>>> have to extend the whole template, but just parts of it.
>>>>>
>>>>> For the admin console it would be best not to require users to extend
>>>>> IMO.
>>>>> We should be able to allow users to view and edit complex attributes (at
>>>>> least a complex attribute that is a list of simple, rather than complex
>>>>> of
>>>>> complex). Initially we could just display the JSON for the complex
>>>>> attribute directly, then create an view/editor for it later.
>>>>>
>>>>
>>>> I just don't want us spending time implementing and maintaining an HTML
>>>> editor for something the user will usually be extending a theme for
>>>> anyways.
>>>
>>> Yes, I totally agree, but that wasn't what I proposed though. What I'd
>>> propose we do is:
>>>
>>> * Admin console - just list claims, sorted by name. For simple types we
>>> display the value and allow editing with input text. For complex we
>>> display json and allow editing in textarea. In the future we can add a
>>> feature that allows view/edit complex attributes directly.
>>> * Registration and account management - only display simple types. We
>>> should provide some mechanism for choosing which are displayed and order.
>>> For complex types or better control on how it's displayed (other than a
>>> simple list of label, input) users are expected to extend the template. In
>>> the future we can add a feature that allows extending parts of a template,
>>> which would make it easier to edit and also maintain in the long run. For
>>> example instead of overriding the whole registration page a user could
>>> override just the form part, or even just how a specific claim is
>>> displayed.
>>>
>>
>> I think users will be extending our themes anyways almost every time
>> (except the admin console).  As, again, anything generically rendered
>> will look ugly and unprofessional.  I started off implementing it the
>> way you are saying...but then I was like, "This is dumb and will look
>> like shit".
>
> I disagree. A lot customization can be done through pure-CSS (have a look at http://www.csszengarden.com/ if you don't believe me) and in the event they need to modify the HTML they most likely only want to change a small part of it. Requiring users to override the registration page just to display a dob field for example is not good usability IMO.
>

Would be nice if you are right, but I don't agree yet.  I don't know 
enough about .css.  Don't you still have to have some semblance of 
structure in your HTML document (field sets and order.  And all this per 
page)?



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com