Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    UI: Alerts vs Static Text Consistency

    Scheduled Pinned Locked Moved
    2.3-RC Snapshot Feedback and Issues - ARCHIVED
    3
    9
    2.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      azzido
      last edited by

      First let me say a big thank you to everyone involved in the new release. It is turning out do be the best pfSense release ever.

      I have noticed that Bootstrap alerts are being used all over the place in the new interface, and they are not being used in a very consistent manner. There are alerts that are displayed to provide feedback for user actions, which work as intended. But then alerts are also used to display static informational text on the page, such as the one on firewall_virtual_ip.php. Some of them are enclosed inside the infoblock, some are not, some infoblocks are open by default some are not. Some pages have alerts + static text outside the alert such as firewall_schedule.php. Then there is the x for closing the alert boxes, some alerts have them, some don't.

      I would like to propose using call outs instead of the alerts for static informational text on the page. I think they accomplish the task a lot better since they do not stand out as much as alert boxes with their coloured background and they have a single purpose, unlike alert boxes now. They take up less space than alert box inside the info block and you don't have to open the info block to see what's hiding inside. I also like that call outs use vertical line instead of horizontal, new UI is a bit heavy on horizontal lines. Here is the call out mock up on few pages. Let me know what you guys think.

      Thanks

      Edit: sorry, images came out a bit large. Here is a link to imgur album http://imgur.com/a/DlszQ




      1 Reply Last reply Reply Quote 0
      • S
        Steve_B Netgate
        last edited by

        Thanks for the mockups. I do like the appearance of the call outs.

        I'm not sure our use of alert blocks is all that inconsistent, but when a new capability is introduced (e.g.: automatic infoblock handling) it takes a while to go back and update all 300 or so UI pages with that technique. The community helps a lot with this stuff, but inevitably we get to some pages before others :) There may be some pages we didn't get to yet.

        Initially all infoblocks defaulted to hidden, but users suggested that on some pages the information really needs to be visible to use the page, but that it is still useful to be able to collapse it. The "blockopen" class was added to allow this. Phil Davis re-did the print_info_block mechanism recently to make it easier to specify the use of the 'close' button. Another example of where we now need to revisit a lot of pages to take advantage of that work.

        We are lucky to have a number of very detail oriented contributors to pfSense :)

        I'll look at making a print_callout() function when time permits.

        Als ik kan

        1 Reply Last reply Reply Quote 0
        • A
          azzido
          last edited by

          Thanks for the quick reply Steve. I created a pull request with initial callout support. 3 pages were converted to use them:

          • system_usermanager.php - basic informational text on the bottom of the page

          • exec.php - scary warning on the top of the page, utilizing heading so you don't miss it

          • services_dnsmasq.php - page with 3 callouts in between the panels

          Hopefully more people can take a look at them and provide feedback.

          1 Reply Last reply Reply Quote 0
          • S
            Steve_B Netgate
            last edited by

            Thanks. I have read through the PR and will start testing it today. Not sure about your removal of theautomated hide stuff, but we'll see what people think.

            Als ik kan

            1 Reply Last reply Reply Quote 0
            • A
              azzido
              last edited by

              I think it really comes down to if we want the text to be shown by default or not.

              If the text is shown by default then I don't think that infoblock is necessary. I don't think anyone will bother closing it, since page does not remember that you did it, so it will be open once you save the page or refresh.

              If the text is hidden by default then infoblock works great.

              As far as hiding or showing the text I think the text should be always shown, just like in v2.2. Most of it is either useful info or helps you not to shoot yourself in a foot, just like the help text next to each form field. If you hide the text, you might as well move it to the help page, since no one will bother checking it.

              I remembered seeing this https://github.com/SjonHortensius/pfsense/issues/8 which got me thinking, why not implement an ability to hide all help text, so if user wants that, they can choose to do it. There could be an option in General setup > webConfigurator that allows you to disable all help text. That would be the best of both worlds.

              1 Reply Last reply Reply Quote 0
              • S
                Steve_B Netgate
                last edited by

                Yes. And here we get into the murky realm of public opinion. When the ability to show/hide an info block was introduced, there was a lot of discussion here about how to use it, which infoblocks would best be started open, etc. People such as Phil Davis, NOYB et al then spent a lot of time going through the project and adding the infoblocks where it made sense. I think this resulted in a very significant improvement to the UI. It made it less cluttered and cleaner looking, particularly on a small screen device.

                Remember that previously we just had alert blocks that could be closed, but not re-opened. So my opinion/guiadnce is that:

                • We should incorporate your new print_callout() function. It offers a further means of improving the UI.

                • We should make use of it on pages where it improves the appearance and where we are clearly not alerting anyone, but just providing hints.

                • The automated show/hide infoblock mechanism should be retained.

                You will find me pointing out more and more that this is Beta software. If we are ever to get to a release candidate we need to understand that Beta means no new features. Bug fixes only :)

                Thanks for your input. I'm not trying to stifle your work, just get to an RC!

                Als ik kan

                1 Reply Last reply Reply Quote 0
                • A
                  azzido
                  last edited by

                  Well, at this point this is not even public opinion, just my opinion, and I understand that these things are very subjective, so I will just put this thing to rest now.

                  I agree with all the items you laid out and will create PRs in the next couple days to replace some alerts with callouts.

                  p.s. thanks for really quick turnaround time on PRs.

                  1 Reply Last reply Reply Quote 0
                  • A
                    azzido
                    last edited by

                    Steve, since you are no longer accepting PRs that change UI, do you want me to continue with this, or table it until post 2.3-RELEASE?

                    Thanks

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      If it's something that fixes a problem, then we're still merging such changes. If it's merely UI improvements, not fixing things that are broken, that's what we're holding off on until post-2.3-RELEASE. Thanks!

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post