Uploaded image for project: 'AeroGear'
  1. AeroGear
  2. AEROGEAR-9811

MDC UI/UX thoughts/suggestions

    XMLWordPrintable

Details

    Description

      I'm probably not a great person to give input on such things, but here are a couple of things I noticed when I was trying to check something in MDC today.

      "Create Mobile App" dialog

      I always feel like I have to choose one of the framework icons.

      When I think about it more, why are these even here? Surely developers could use these or any other frameworks, or no framework, if they want?

      Also, why is there an asterisk beside the field name? (* App Name)

      Menu on mobile app card

      It seems a little redundant to have a menu with a single "delete" entry on these. Why not have a "Delete" button (or an icon or something) instead? Or maybe a checkbox, so that I can check multiple, and once there's one or more selected, an obvious delete button appears (I'm thinking like how I long press on a photo or something on a mobile phone to go into like a select mode or whatever, and then batch action buttons appear somewhere).

      Configuration tab of mobile client page

      On the "create mobile app" dialog I mentioned above, there were 5 framework icons, and they were colourful. In here there are 2 choices and they're not colourful. Why only two?

      Mobile Services tab of mobile client page

      • The list of services on the left have a title and a subtitle. These appear to want to be "Capability" and "Providing service" respectively, but if so, don't do a great job of it.
      • "Identity Management Service" isn't a thing, "Red Hat Single Sign-On is the thing
      • "Data Sync Service" isn't really a thing either, you have to bring your own
      • Why does it say "Mobile Security Service" and "Unified Push Server" for both title and subtitle?
      • Not a huge fan of the bind/unbind terminology that we've kind of just inherited from the old Ansible service broker world. In RHMI, all managed services are provisioned all the time, so maybe we could remove the two sections "Bound Services" and "Unbound Services", and just have a list of services? For the generic "Bind to App" buttons (that are way over on the other side of the screen for some reason, and on a wide screen I need to make sure I'm clicking on the correct one (maybe I should be able to just click on the text or icon?)), how about something more indicative of what that means, such as "Create Realm" or "Create Variant" (I don't know what to say for the others). This became more confusing to me when I clicked "Bind to App" for Push, and then it went to the "Bound Services" section, but it still had a "Bind to App" button, since I could still create one of the other type of variant (Android/iOS).

      I think some of the changes here are good, but then some of the others are just there as an idea to make a point:

      Binding dialog for Push

      ^should say either of "[...], needed to connect to FCM" or "[...], needed for connecting to FCM"

      ^ First field header (iOS .p12 file) doesn't start with "The", but second field header does. I'd suggest removing from the second one. Also, UPS uses file upload for that cert input, do we really need people to perform a magic base64 spell beforehand here in MDC for it?

      The 3rd screen that temporarily appears in the dialog, saying "you can close this wizard" right before it closes itself before you finish reading what it says (or before I can screenshot for here), seems unnecessary. If it's kept, maybe just have it contain a giant green tick for success.

      "Unified Push Server" vs. "UnifiedPush Server"

      UPS calls itself "UnifiedPush Server", but MDC calls it "Unified Push Server".

      Why can I only create one variant of each type for Push?

      UPS seems to allow more than one variant of each type (I created the second through its own UI):

      Also (not really a UI/UX thing), in the above image, why does the one created by MDC have a suffix of "-android-ups-variant"? That could cause unnecessary name length problems if that edge case isn't covered – if a MobileClient CR had a name that approached the 253 character limit for k8s resources, and that suffix brought it over the limit, what would happen? If we're only ever going to allow one variant of each type, they could maybe both have the same name as the MobileClient CR itself.

      Attachments

        Activity

          People

            Unassigned Unassigned
            gryan@redhat.com Gerard Ryan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: