First demo of UI

887×256 3.32 KB

Hi everyone,

The Prototype

September is here, which means it’s time for the first demo of the UI that you can get your hands on and actually click around in, on your own.

3 things to consider before you use the prototype:

1. Make sure you view it at 100% size, or it will be hard to read the text.
2. At any time, hold down the SHIFT key to highlight anything that you can click on
3. The screens are pre-populated with search results, etc. to demonstrate that the user who logs back in can continue their workflow from where they left off when they logged out. The amount of data on the screens when they launch can seem daunting for that reason. Just know that the actual experience will be a different one if all the data you see is stuff you remember finding yourself—just like when you open your laptop, lots of programs, documents, folders and browser tabs might be open, but it’s not confusing in the same way, because you opened all the programs yourself and you understand where it all came from

I developed this prototype to give you a good feeling of the basic structure of the framework and some basic apps and how it all plays together. The prototype is a living thing, so it will continue to evolve with time. It’s not super specific on all the pages and since it is only a prototype, some basic concepts might be helpful to have explained to you; I recommend checking out my initial presentation of the design work here, where I go over the navigation structure, importing and exporting files, saving search results and much more: https://www.openlibraryenvironment.org/archives/184

The prototype: https://pr.to/D7XIAW/

The UX principles for Folio and for Folio apps

Find the UX principles here: https://docs.google.com/document/d/1018RtOkhuBXdPlxb03gwY5Je4LdeZeI8_cv6N8NlHQE/

For a walk-through of the UX/UI principles, have a look at https://www.openlibraryenvironment.org/archives/184. The UX and UI principles will get more and more tangible and practical as we figure out how the UI will be implemented technically (it all ties together)—so if you find the current principles very abstract, don’t be dismayed: As soon as we know more about the actual way to write good markup, good styling and good interactions for the Folio platform, we will be updating the UX/UI principles with actual code snippets, etc.

##Daily design bites
Starting this Monday, I will be posting a short update every weekday, focusing on an individual function or area of the interface. Explaining, asking questions, following up on feedback and questions to the video and the prototype, etc.

##A conversation kickstarter
I hope this will serve as a good conversation starter for us all to talk about what’s important for libraries day-to-day—now and in the future.

I look forward to developing the UX and UI further together with you all

@filipjakobsen…this looks great! Very clean and nicely laid out for efficient access to functions. It will be good to see what practitioners have to say since it is hard for me to get a sense of how deep in any web-based hierarchy they would need to go to do common activities.

For example, in the demo, I land on a profile page for John Doe as a result of a search (presumably this could have been triggered by scanning John’s ID card). If I were to scan a book barcode from this screen, would the system move right into the checkout function?

One other thing I noticed, that may be an artifact of this being a demo, is that the shading on the left hand menu sometimes stays on when i move my mouse quickly (the trigger event for leaving the menu link does not fire?).

@michael.winkler Thanks,

The thought is that if the user scans anything at any time, then it would open up that thing to preview and potentially do something with. After discussing with Circulation SMEs it has become clear that we need a dedicated Check out and Check in layout in addition to the general scanning layout. That’s why the Scan app in the prototype has the dropdown in the top left corner to choose between modes; Each mode shows the appropriate amount of information for that specific task (checking in, checking out, general scanning in other settings)

The shading that “stays on” after hovering something is an artefact of the prototyping tool I use. It will not translate into the actual product. And you’re right—it shouldn’t be like that in the end

It’s very exciting to see the first demo of what the Folio UI might look like!

There are many interesting ideas being proposed in this layout. Of course, these are presented from a UX perspective - a user experience perspective.

I think it would be interesting to also explore this UI from an app experience perspective (AX?). What I mean by this is to explore and highlight how an app interacts with the UI, rather than how a user interacts with it. One can already catch a glimpse of this from the existing demo. For instance: an app gets to drop an icon in the toolbar (right half of header); an app can carve out a section for itself on the preferences screen; an app can provide a “home page” for itself; etc…

Another way to think about it is as a deconstructed UI. Consider the following thought experiment. Take a Folio instance and remove all the apps. What would be left? That’s the baseline from the app perspective. Then we add one app back. Where does it “hook into” the UI? We already know that it can add an icon to the toolbar, provide a home page, expose preferences. What else can it do? For instance, can an app attach itself to other apps (e.g. into the home page of another app) in order to extend its functionality? Alternatively, what must an app do? For instance, can an app be invisible to the UI?

@filipjakobsen Perhaps the app perspective is something that you might entertain as the topic of a Daily BIte?

5 posts were split to a new topic: Making a distinction between patrons and system users, particularly with a perspective on permissions

I see alot of similarities with IOS here. Interaction and design language,such as icon use. Are these going to be changeable into a more general templates in settings or is this “It”.?

Hi Martin,

Thanks for your comment!

To ensure maximum global usability, we will have to stick to a universal theme for the system. What is shown here is the default, light theme. We will also develop a dark theme, and potentially a high-contrast theme for accessibility purposes. In addition the font size and panel sizes in the system can be adapted by the user, and all elements will adapt their layout to the given screen sizes.

The philosophy behind the prevalent design languages in the market today (like iOS, Mac OSX, Windows Metro, Google’s Material Design, Bootstrap) is also the philosophy we adhere to in this project: Making the interface as neutral, functional and subtle as possible to put maximum focus on the content. We are striving to create something that is simple, modernist, pragmatic and inconspicuous.

We did think about allowing people to style the interface extensively to match their brand colors, etc. With the need for a UI library that is ready-to-use for developers as well as the goal of optimizing readability and usability for the end user even with third-party apps, our current thought is to keep one styling for the system that is color-neutral (black, white and grey not being colors in the spectrum, but the presence and absence of light), makes use of space efficiently and lets everyone focus on great functionality rather than styling.

So currently the plan is to let each installation of Folio allow you to add your organization logo, potentially branch logos, and app developers can provide a unique icon for the apps they publish if they wish to.

This seems to be an approach that is common, even in administrative interfaces, for many non-library domain tools - light branding, minimal styling, focus on function or content. Given that most of the UI would be library staff facing, heavy branding, styling, or marketing seems unnecessary. Many parts of FOLIO that may face non-staff users, would likely be wrapped inside other systems (resulting in needless over branding).

This approach makes sense to me.

@vbar Thanks for your comment!

I will write a Design Bite post on the topic of app types and how they are reflected in the different parts of the interface in the near future.

@filipjakobsen Thank you for your reply and explanation. With regards to @michael.winkler comment as well, i would somewhat agree and disagree. Looking at the libraries which i work with, being several university libraris, one thing i have noticed is the different requirements for handling the same things. Many aspects are involved. There isn’t a set way in which everything is done at a library but rather small differences in how a list is shown, what information is in the list, depending on what that specific library sees as more important information. Therefore having an option to somewhat edit the UI, and how things are shown has little to do with branding or marketing, but rather configurating the system to solve that libraries specific needs. If FOLIO intends to be catered towards many libraries, and different kinds of libraries, i would atleast recommend that many things, including big parts of the UI to be configurable. The other solution would be to try to convince libraries to start using the same processes and routines, which isnt as easy as it sounds. just a thought =).

@MartinL I absolutely agree that we should support optimization of users’ individual workflows. We will make as much of the interface configurable to the users; your example with metadata in a list is one of the things the user will be able to configure on a per-list basis —so for the “list” element we will provide for Folio, there is built in a “filter displayed data” option by default. So for any given list one user might want to view name and photo. Others might want to view name, photo, id number and phone number. What to view in a given list would be configurable for each user.

If you have any other specific examples of UI customization you think are important, please do share so we can make the product as efficient and flexible as possible )

I would suggest keeping accessibility guidelines in mind even for color-neutral styles. People who are color-blind frequently rely on contrast to distinguish between shades, so if you have a bunch of grays together, they need to be distinguishable. We ran into this recently with our room booking system, where the green “available” squares were the same shade as the gray “not available” squares, and a staff member couldn’t tell the difference.

@ekelistic We will definitely keep that in mind while designing the system!

I love the openness and collaboration in publishing the FOLIO UX Values document.

Piling on to Laurel’s comment about visual/contrast accessibility, I notice there’s no specific mention in the UX doc of accessibility compliance. As FOLIO is, at its very heart, a web application, it’d be great to select and conform to a web a11y level of expected compliance for all UI/UX elements, e.g. WCAG 2.0. Themes and colors are a good start, but a commitment to web accessibility will mean that other important structural features aren’t overlooked – e.g. labels on form controls, appropriate image or object descriptions, “skip” links for page navigation, visual display equivalents for audio alerts, &c. Articulating a standards-based expectation could ease the development process, while also helping to ensure that final products are accessible.

Is this link still the current prototype?

The prototype: https://pr.to/D7XIAW/

Thanks,
James

Hi James,

Yes, that is the link to the UX prototype.

Best,

Charlotte (Index Data)