Getting involved in a developer community can be highly rewarding, but entails risk as well. When we speak at conferences, give a demo, or even just attend an event, we make ourselves vulnerable. We open ourselves for criticism, rejection, and sometimes harassment. We don't think we're qualified to be here, we don't think we'll be accepted socially. So what can we do? Making our community a safe and welcoming place is the responsibility of everyone involved, not just the organizers. Bryan will talk about his own journey into the NodeBots community, and some of the things he has learned about community over the years.
Bryan Hughes is a front-end engineer at Rdio, and an organizer for the NodeBots SF meetup group, and a somewhat regular speaker at conferences. In his spare time he likes to do robotics work with the Raspberry Pi and JavaScript, having added support for the Raspberry Pi to the Johnny-Five robotics library.
Open source started it and the world is following" can describe many phenomena; it certainly describes remote working. What lessons can we learn from Mozilla when it comes to wrangling groups of contributors across geographies, cultures, skill sets and a number of other diverse characteristics?
Diane has worked with developers in a variety of capacities: as a recruiter, a product manager at Schwab and for various startups, and as program manager at Mozilla building out both its developer startup program, WebFWD as well as wrangling the developer relations team. She appreciates her video camera and its ability to bridge gaps of time and space and wants to take the "hate" out of the common love-hate relationship many have with remote working.
Creating good documentation is hard. Creating good documentation for developers is almost impossible. In Auth0, we’ve faced that problem since we’re a developer focused startup. In this session, I’ll talk about our experience creating the documentation and some very useful tips and things every documentation aimed for developers should have.
"Martin Gontovnikas has been a tech nerd since he was 12 years old. Now, he's a web developer, trainer, speaker and writer. He currently works as a Developer Advocate at Auth0.
He's a big advocate and contributor for Open Source sofware. He has built Restangular, angularytics, factory_pal, angular-jwt and many more!
He (not so) frequently blogs at http://gon.to/blog/ and has spoken at Devoxx, ngEurope and dotJS among others."
Writing high quality, maintainable client-side code is becoming increasingly important as we continue to move more logic into the browser. We should treat our client-side code with the respect it deserves.
In this talk I'll show how we can use unit-testing to make our JavaScript apps better. We'll briefly cover the fundamentals of unit-testing and what tools are available for testing client-side code. We'll then dive into real-world examples, looking at how to unit-test a simple backbone app, test-first. We'll see how testing drives us towards cleaner and more maintainable code, with clear separation between the DOM and your application logic. Along the way we'll also learn a few JavaScript testing protips(tm).
Pete is a Lead Consultant at ThoughtWorks. He helps teams get more awesome at delivering maintainable software at a sustainable pace, using agile practices like test-driven design, pairing and continuous delivery. After horrible experiences with JavaScript in the early 2000s Pete saw the light and fell in love with this quirky little language while leading a team building a pure-JavaScript single-page mobile banking application. He's also a fan of functional programming, dynamic languages, hypermedia API design, and brewing his own beer.
"With billions of people using the Internet, the potential for nefarious or outright criminal users hitting your site is very high. With attacks ranging from MITM, CSRF, Script Injection, Clickjacking to name a few, it is imperative that we as developers understand these exploits, how they work, how they can be stopped, and how to implement the code or setup to do so. As developers, we tend to focus on the core of what our application does. Unfortunately, security tends to be overlooked or at best an afterthought.
In this talk we will explore the OWASP top 10 web application security flaws including how they work and best practices to protect your application from them. The focus will be on Express web applications in Node, but the principles shown can be applied to any framework or environment."
Scott Smith is a VP of Product Development during the day and full stack Node and .NET developer by night. Most recently Scott created Coderbits, an intelligent portfolio site for developers and designers, and sold it to Appirio to power their Top Coder platform. He has a passion for REST APIs and loves sharing that passion with others. When not working, you will probably find him SCUBA diving on a tropical island.


Important tags to remember h1-h6, p main, header, footer, article, secton strong, span, em from,input, button, label This is the first point this is a second point


sheeranalyticsandinsights.com HTML Site Map
Last updated: 2020, June 13 06:40:55
Total pages: 144
sheeranalyticsandinsights.com Homepage
/
13 pages
sheeranalyticsandinsights.com
news-and-resources
press-release
blog
submit-query
consulting-solutions
it-solution-consulting
passport-reports
company-profile
syndicate-reports
data-market-monitoring
about-us
contact-us
report/
6 pages
consumer-oriented-sectors
technology-sectors
defence-aerospace-automotives
life-sciences
chemicals-materials-energy
banking-financial-insurance
sect/
35 pages
other-consumer-goods
home-care
travel-and-tourism
packaging
footwear
baby-care
pet-care
food-ingredients
alcoholic-beverages
health-&-beauty
food
civil
electrical
shipping-and-heavy-machinery
instrumentation
photonics
automation
communication-and-technology
semiconductors
electronics
other-transportation
services
aerospace
automotives
defence
biotechnology
pharmaceuticals
medical-devices
health-care
materials
energy
chemicals
insurance
financial
banking
reg/
7 pages
asia-pacific
cee
latin-america
middle-east-and-africa
north-america
western-europe
global
sect/
67 pages
china
india
indonesia
pakistan
japan
philippines
vietnam
thailand
south-korea
malaysia
taiwan
australia
hong-kong
singapore
new-zealand
sri-lanka
russia
turkey
ukraine
poland
romania
czech-republic
hungary
bulgaria
baltic-states
slovakia
croatia
slovenia
latvia
lithuania
estonia
uruguay
venezuela
chile
peru
colombia
argentina
brazil
mexico
nigeria
egypt
south-africa
morocco
saudi-arabia
israel
uae
ghana
kenya
iran
algeria
us
canada
germany
france
uk
italy
spain
netherlands
greece
portugal
belgium
sweden
austria
switzerland
finland
norway
global
market-report-research/
8 pages
3d-motion-capture-systems-market-21
patient-safety-and-risk-management-software-market-21
patient-handling-equipment-market-21
outpatient-surgical-procedures-market-21
home-healthcare-market-21
Disposable-protective-clothing-market-21
global-lyocell-fiber-market-21
latest-published-reports
press/
8 pages
3d-motion-capture-systems-market
patient-safety-and-risk-management-software-market
patient-handling-equipment-market
outpatient-surgical-procedures-market
home-healthcare-market
bronchial-thermoplasty-market
global-3d-printing-market
infusion-pumps-market


{% from "components/card.html" import card %} {% extends "base.html" %} {% block content %} {% call card("You are not allowed to view this page.") %} You do not have the proper permissions to view this page. Return to Site {% endcall %} {% endblock %}
You do not have the proper permissions to view this page.


| | |
- electrostatic_potentials(file_name)
- Returns the dielectic constant for the various solvents within the
database. If a solvent is not in the list will return 1. Takes a
string and returns a double
Sources:
acetic acid to water (pH 7):
https://www.organicdivision.org/wp-content/uploads/2016/12/ organic_solvents.html
Glycerol - Sulfuric Acid:
http://www.appliedmc.com/content/images/Dielectric_Constants.pdf
Chloronaphthalene - http://www.stenutz.eu/chem/solv6.php? name=1-chloronaphthalene
3-methylpentante - https://journals.aps.org/pra/pdf/10.1103/ PhysRevA.42.4735
PBS - http://www.materials-talks.com/blog/2015/03/09/how-to-get-the -latest-software-for-the-zetasizer-nano/
Borate Buffer - https://www.honeywellprocess.com/library/marketing/ tech-specs/Dielectric%20Constant%20Table.pdf
Sodium Hydroxide - http://www.microkat.gr/msdspd90-99/Sodium%20 hydroxide.html
- get_absorption_files(data_dir)
- Get the total files containing absorption spectra. Expects the files to
be of type *.txt and have the naming convention *.abs.txt will return a
list of strings to be parsed later.
- get_emission_files(data_dir)
- Get the total files containing emission spectra. Expects the files to
be of type *.ems.txt and have the naming convention *.ems.txt will return
a list of strings to be parsed later.
- get_molecule_cid(file_name)
- Take a file_name, remove the ending and prefix and return the pubchem
molecule object. If the file_name does not have the cas number, try the
name of the system, else return None so as to disreguard the molecule
from training.
- get_peaks(spectra)
- get_spectra(file_name)
- Iterates through the file and pulls out the normalized spectrum contained
within. The X is in wavelentgh, and the intensity is normalized to the
most intense peak.
|


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Object org.jasypt.digest.config.SimpleDigesterConfig org.jasypt.digest.config.EnvironmentDigesterConfig
public class EnvironmentDigesterConfig
Implementation for DigesterConfig
which can retrieve configuration
values from environment variables or system properties.
The name of the environment variable or system property (JVM property) to query for each parameter can be set with its corresponding setXEnvName or setXSysProperty method.
As this class extends SimpleDigesterConfig
, parameter values
can be also set with the usual setX methods.
For any of the configuration parameters, if its value is not configured in any way, a null value will be returned by the corresponding getX method.
| Constructor Summary | |
|---|---|
EnvironmentDigesterConfig()
Creates a new EnvironmentDigesterConfig instance. |
| Method Summary | |
|---|---|
String |
getAlgorithmEnvName()
Retrieve the name of the environment variable which value has been loaded as the algorithm. |
String |
getAlgorithmSysPropertyName()
Retrieve the name of the JVM system property which value has been loaded as the algorithm. |
String |
getIterationsEnvName()
Retrieve the name of the environment variable which value has been loaded as the iteration count. |
String |
getIterationsSysPropertyName()
Retrieve the name of the JVM system property which value has been loaded as the iteration count. |
String |
getProviderClassNameEnvName()
Retrieve the name of the environment variable which value has been loaded as the provider class name. |
String |
getProviderClassNameSysPropertyName()
Retrieve the name of the JVM system property which value has been loaded as the provider class name. |
String |
getProviderNameEnvName()
Retrieve the name of the environment variable which value has been loaded as the provider name. |
String |
getProviderNameSysPropertyName()
Retrieve the name of the JVM system property which value has been loaded as the provider name. |
String |
getSaltGeneratorClassNameEnvName()
Retrieve the name of the environment variable which value has been loaded as the salt generator class name. |
String |
getSaltGeneratorClassNameSysPropertyName()
Retrieve the name of the JVM system property which value has been loaded as the salt generator class name. |
String |
getSaltSizeBytesEnvName()
Retrieve the name of the environment variable which value has been loaded as the salt size in bytes. |
String |
getSaltSizeBytesSysPropertyName()
Retrieve the name of the JVM system property which value has been loaded as the salt size in bytes. |
void |
setAlgorithm(String algorithm)
Sets the name of the algorithm. |
void |
setAlgorithmEnvName(String algorithmEnvName)
Set the config object to use the specified environment variable to load the value for the algorithm. |
void |
setAlgorithmSysPropertyName(String algorithmSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the algorithm. |
void |
setIterations(Integer iterations)
Sets the number of hashing iterations. |
void |
setIterations(String iterations)
Sets the number of hashing iterations. |
void |
setIterationsEnvName(String iterationsEnvName)
Set the config object to use the specified environment variable to load the value for the iteration count. |
void |
setIterationsSysPropertyName(String iterationsSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the iteration count. |
void |
setProvider(java.security.Provider provider)
Sets the security provider to be used for obtaining the digest algorithm. |
void |
setProviderClassName(String providerClassName)
Sets the class name for the security provider to be used for obtaining the digest algorithm. |
void |
setProviderClassNameEnvName(String providerClassNameEnvName)
Set the config object to use the specified environment variable to load the value for the provider class name. |
void |
setProviderClassNameSysPropertyName(String providerClassNameSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the provider class name. |
void |
setProviderName(String providerName)
Sets the name of the security provider to be asked for the digest algorithm. |
void |
setProviderNameEnvName(String providerNameEnvName)
Set the config object to use the specified environment variable to load the value for the provider name. |
void |
setProviderNameSysPropertyName(String providerNameSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the provider name. |
void |
setSaltGenerator(SaltGenerator saltGenerator)
Sets the salt generator. |
void |
setSaltGeneratorClassName(String saltGeneratorClassName)
Sets the class name of the salt generator. |
void |
setSaltGeneratorClassNameEnvName(String saltGeneratorClassNameEnvName)
Set the config object to use the specified environment variable to load the value for the salt generator class name. |
void |
setSaltGeneratorClassNameSysPropertyName(String saltGeneratorClassNameSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the salt generator class name. |
void |
setSaltSizeBytes(Integer saltSizeBytes)
Size in bytes of the salt to be used. |
void |
setSaltSizeBytes(String saltSizeBytes)
Size in bytes of the salt to be used. |
void |
setSaltSizeBytesEnvName(String saltSizeBytesEnvName)
Set the config object to use the specified environment variable to load the value for the salt size in bytes. |
void |
setSaltSizeBytesSysPropertyName(String saltSizeBytesSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the salt size in bytes. |
| Methods inherited from class org.jasypt.digest.config.SimpleDigesterConfig |
|---|
getAlgorithm, getIterations, getProvider, getProviderName, getSaltGenerator, getSaltSizeBytes |
| Methods inherited from class Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
|---|
public EnvironmentDigesterConfig()
Creates a new EnvironmentDigesterConfig instance.
| Method Detail |
|---|
public String getAlgorithmEnvName()
public void setAlgorithmEnvName(String algorithmEnvName)
algorithmEnvName
- the name of the environment variablepublic String getAlgorithmSysPropertyName()
public void setAlgorithmSysPropertyName(String algorithmSysPropertyName)
algorithmSysPropertyName
- the name of the propertypublic String getIterationsEnvName()
public void setIterationsEnvName(String iterationsEnvName)
iterationsEnvName
- the name of the environment variablepublic String getIterationsSysPropertyName()
public void setIterationsSysPropertyName(String iterationsSysPropertyName)
iterationsSysPropertyName
- the name of the propertypublic String getSaltSizeBytesEnvName()
public void setSaltSizeBytesEnvName(String saltSizeBytesEnvName)
saltSizeBytesEnvName
- the name of the environment variablepublic String getSaltSizeBytesSysPropertyName()
public void setSaltSizeBytesSysPropertyName(String saltSizeBytesSysPropertyName)
saltSizeBytesSysPropertyName
- the name of the propertypublic String getSaltGeneratorClassNameEnvName()
public void setSaltGeneratorClassNameEnvName(String saltGeneratorClassNameEnvName)
Set the config object to use the specified environment variable to load the value for the salt generator class name.
The salt generator class name which is set here must have a no-argument constructor, so that it can be instantiated and passed to the digester.
saltGeneratorClassNameEnvName
- the name of the environment variablepublic String getSaltGeneratorClassNameSysPropertyName()
public void setSaltGeneratorClassNameSysPropertyName(String saltGeneratorClassNameSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the salt generator class name.
The salt generator class name which is set here must have a no-argument constructor, so that it can be instantiated and passed to the digester.
saltGeneratorClassNameSysPropertyName
- the name of the propertypublic String getProviderNameEnvName()
public void setProviderNameEnvName(String providerNameEnvName)
Set the config object to use the specified environment variable to load the value for the provider name.
providerNameEnvName
- the name of the environment variablepublic String getProviderNameSysPropertyName()
public void setProviderNameSysPropertyName(String providerNameSysPropertyName)
providerNameSysPropertyName
- the name of the propertypublic String getProviderClassNameEnvName()
public void setProviderClassNameEnvName(String providerClassNameEnvName)
Set the config object to use the specified environment variable to load the value for the provider class name.
The provider class name which is set here must have a no-argument constructor, so that it can be instantiated and passed to the digester.
providerClassNameEnvName
- the name of the environment variablepublic String getProviderClassNameSysPropertyName()
public void setProviderClassNameSysPropertyName(String providerClassNameSysPropertyName)
Set the config object to use the specified JVM system property to load the value for the provider class name.
The provider class name which is set here must have a no-argument constructor, so that it can be instantiated and passed to the digester.
providerClassNameSysPropertyName
- the name of the propertypublic void setAlgorithm(String algorithm)
SimpleDigesterConfig
Sets the name of the algorithm.
This algorithm has to be supported by your security infrastructure, and it should be allowed as an algorithm for creating java.security.MessageDigest instances.
If you are specifying a security provider with SimpleDigesterConfig.setProvider(Provider)
or
SimpleDigesterConfig.setProviderName(String)
, this algorithm should be
supported by your specified provider.
If you are not specifying a provider, you will be able to use those algorithms provided by the default security provider of your JVM vendor. For valid names in the Sun JVM, see Java Cryptography Architecture API Specification & Reference.
Determines the result of: SimpleDigesterConfig.getAlgorithm()
setAlgorithm
in class SimpleDigesterConfig
algorithm
- the name of the algorithm.public void setIterations(Integer iterations)
SimpleDigesterConfig
Sets the number of hashing iterations.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getIterations()
setIterations
in class SimpleDigesterConfig
iterations
- the number of iterations.public void setIterations(String iterations)
SimpleDigesterConfig
Sets the number of hashing iterations.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getIterations()
setIterations
in class SimpleDigesterConfig
iterations
- the number of iterations.public void setSaltSizeBytes(Integer saltSizeBytes)
SimpleDigesterConfig
Size in bytes of the salt to be used.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getSaltSizeBytes()
setSaltSizeBytes
in class SimpleDigesterConfig
saltSizeBytes
- the size of the salt, in bytes.public void setSaltSizeBytes(String saltSizeBytes)
SimpleDigesterConfig
Size in bytes of the salt to be used.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getSaltSizeBytes()
setSaltSizeBytes
in class SimpleDigesterConfig
saltSizeBytes
- the size of the salt, in bytes.public void setSaltGenerator(SaltGenerator saltGenerator)
SimpleDigesterConfig
Sets the salt generator.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getSaltGenerator()
setSaltGenerator
in class SimpleDigesterConfig
saltGenerator
- the salt generator.public void setSaltGeneratorClassName(String saltGeneratorClassName)
SimpleDigesterConfig
Sets the class name of the salt generator.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getSaltGenerator()
setSaltGeneratorClassName
in class SimpleDigesterConfig
saltGeneratorClassName
- the name of the salt generator class.public void setProviderName(String providerName)
SimpleDigesterConfig
Sets the name of the security provider to be asked for the digest algorithm. This provider should be already registered.
If both the providerName and provider properties are set, only provider will be used, and providerName will have no meaning for the digester object.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getProviderName()
setProviderName
in class SimpleDigesterConfig
providerName
- the name of the security provider.public void setProvider(java.security.Provider provider)
SimpleDigesterConfig
Sets the security provider to be used for obtaining the digest
algorithm. This method is an alternative to
both SimpleDigesterConfig.setProviderName(String)
and
SimpleDigesterConfig.setProviderClassName(String)
and they should not be used
altogether.
The provider specified with SimpleDigesterConfig.setProvider(Provider)
does not
have to be registered beforehand, and its use will not result in its
being registered.
If both the providerName and provider properties are set, only provider will be used, and providerName will have no meaning for the digester object.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getProvider()
setProvider
in class SimpleDigesterConfig
provider
- the security provider object.public void setProviderClassName(String providerClassName)
SimpleDigesterConfig
Sets the class name for the security provider to be used for
obtaining the digest algorithm. This method is an alternative to
both SimpleDigesterConfig.setProviderName(String)
SimpleDigesterConfig.setProvider(Provider)
and they should not be used altogether.
The provider specified with SimpleDigesterConfig.setProviderClassName(String)
does not
have to be registered beforehand, and its use will not result in its
being registered.
If both the providerName and provider properties are set, only provider will be used, and providerName will have no meaning for the digester object.
If not set, null will be returned.
Determines the result of: SimpleDigesterConfig.getProvider()
setProviderClassName
in class SimpleDigesterConfig
providerClassName
- the name of the security provider class.
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Get OpenStreetMap Data for a Feature
Select a feature
atm
bank
bar
bicycle_parking
bicycle_rental
cafe
cinema
fire_station
fuel
library
post_box
restaurant
school
theatre
Click the rectangle icon to select an area for which you want data.
Get Feature Data!


Sun Web Application Guidelines - Version 4.1
|
| Search Guidelines | Send Feedback | Developers.sun.com |
| [ Table of Contents | 0 Revision History | 1 Introduction | 2 Visual Design | 3 Windows and Pages | 4 Mastheads | 5 Top-Level Navigation | 6 Content Area | 7 Simple Elements | 8 Complex Elements | 9 Tables | 10 Topology | 11 Contextual Help | 12 Search | 13 Wizards | 14 Alerts and Messages | 15 Progress Indicators | 16 Alarms and Status Indicators | 17 Login Page | 18 Version Page | Appendices ] |
How To Use These Guidelines - An Introduction
5.1 Choosing a Navigation Style
5.1.2 Tabbed Panes and Accordion
5.1.5 Pop-Up Windows for Objects
5.1.6 Combinations of Navigation Styles
<IP_ADDRESS> Drill Down in Left Pane
<IP_ADDRESS> Tree or Flat List in Left Pane of a Tabbed Pane
<IP_ADDRESS> Drill Down in Left Pane of a Tabbed Pane
5.2 Tabbed Panes and Accordion Details
5.2.3 Three-Level Tabbed Panes
5.2.4 Tabs within a Sun.com Web Site Page
5.3 Left-Right Pane Set Details
<IP_ADDRESS> Application Actions Versus Application Objects
<IP_ADDRESS> Types of Container-Nodes
<IP_ADDRESS> Alarm or Status States of Tree Objects
<IP_ADDRESS> Scaling Methods for Trees
5.5.1 Access to the Common Tasks Page
<IP_ADDRESS> Navigational Tasks: Flow Diagrams
<IP_ADDRESS> Action-Based Tasks: Flow Diagrams
Chapter 3, Windows and Content Pages, describes the highest, broadest view of Web Application UIs. Those topics nest top-level navigation within them, so you should read Chapter 3 before reading this chapter. Top-level navigation nests lower-level navigation within it, so you should read this chapter before Chapter 6, Content Area Structure and Layout.
Top level navigation is the "main thoroughfare" that takes the user from the opening of an application to the content area where the user works. Methods of top level navigation are typically trees, tabs, or a drill-down method that uses textual or graphical links on each page, and which may leave breadcrumbs for the user as a return path.
Once users navigate to the area where they want to work, they may encounter content area navigation, consisting of links, buttons, and dropdown menus. Tabs can also be used for content area navigation (for example, when a tree is used for top-level navigation, the content page associated with the selected tree node may display a set of tabs).
This chapter is not an exhaustive list of all the top-level navigation styles that might be allowed. Instead, this chapter lists the styles that have been defined so far. More styles may be defined in future updates of these guidelines.
"Summary representation" and "detailed representation" are terms used throughout this chapter. Summary representations of objects are relatively small summary representations such as rows in a tree, list, or table, or icons in a topology view. Being small, summary representations are convenient for showing a lot of objects at once. However, the small size of summary representations makes it hard to design a summary representation to show all of an object's attributes, and especially hard to show controls for editing the attributes.
Detailed representations exist to overcome those disadvantages. Examples of detailed representations include:
The manner in which detailed representations are made to appear differs depending on the particular representation and the navigation style, as follows.
The concepts of "summary" and "detailed" representations are clarified in the remaining sections of this chapter, which describe several top-level navigation styles.
"Wormholing" is a navigational mechanism that is orthogonal to all the other navigational mechanisms described in the remainder of this chapter. Wormholing is the selecting of a link that leads directly to a drastically different place in the UI, skipping the normal steps for navigating to that place. Wormholing is offered as a convenience to users, to save them the trouble of laboriously navigating through the formal structure of the UI, to get to some named object or place.
As an example of a wormhole, suppose a product has tabbed panes as its top-most navigational structure. Within each tabbed pane there is a left-right pane set, and within the left pane is a tree. The user has made her way to one of the tabbed panes. She laboriously expands nodes of the tree, and finally focus-selects an object to see its properties in the right pane. Suppose that in that right pane is the name of a related object that exists in a different tabbed pane, which is far down that tabbed pane's own tree structure. To get there using the normal steps for navigating to that object, the user would need to write down the exact location of that object, then laboriously work down that other tabbed pane's tree to the correct node. That laborious navigation method must be available, because it is part of the fundamental structure of the product. However, as a convenience to the user, the designer may also make that related object's name a link. Clicking that link instantly switches to that other tabbed pane, expands that tree to the correct node, and then focus-selects that object. That linked object name is a "wormhole."
When the user takes a wormhole (clicks on a wormhole link), change the display to the same appearance it would have had if the user had reached that destination using normal (usually more laborious) steps for navigating to the resulting place. Make the appropriate tabs active, expand trees to the appropriate nodes, focus-select the appropriate nodes, and display breadcrumbs and parentage paths as if the user had manually drilled down to that destination.
Independent of Navigation Style, sometimes it is better to show many objects in full detail on one page than to force the user to see each of their details only after drilling down to individual pages. It is appropriate to show multiple objects' detailed representations simultaneously on a single page when all of these conditions are met:
Generally, when multiple detailed representations of objects are shown on a single page, each object should be shown in its own section, or otherwise clearly labeled and distinguished from the other objects.
No single top-level navigation style is clearly superior to the others. Each style has advantages and disadvantages making it suitable for particular situations. The trade-offs are too complex to capture in a simple table or flow chart to prescribe your choice of a style. Future releases of the style guide may provide lists of advantages and disadvantages in the sections that follow.
This table is merely an introductory overview that shows a small subset of the reasons for choosing each style. For detailed descriptions of the styles, click their linked names in the left column of this table.
| Top-Level Navigation Style | Highlights of Appropriate Usage |
|---|---|
|
Drill down. Content area shows attributes of one item at a time, with a parentage path or breadcrumb at the top. |
One item at a time is open. Switching among items quickly is unimportant. Tall and wide content area. |
| Tabbed panes. One to three levels of tabbed panes, each tabbed pane representing one category or item. | Six or fewer tabs within each level of tabs, one to three levels of tabs. Content area more complex than navigation area. Wide content area. |
To allow quick access to an applications' top level objects while maintaining page context. Offers a vertically-oriented, collapsible top-level navigation panel. The contents of an accordion container are mostly views or categories of objects rather than objects themselves. |
|
| Left-right pane set. Focus-selecting an item in the left pane shows its attributes in the right pane. | Navigation area more complex than content area. Tall content area. Switching among items quickly is important. |
| Tree. Vertical list that is indented for each level in a hierarchy. | Seven or more categories. Multiple, similar levels in one hierarchy. |
| Pop-up windows. Main window shows names of objects. Attributes of an opened object are shown in a pop-up browser window. | Multiple items open at once. Tall and wide content area. |
| Combinations of the above styles, such as tree in the left pane of a left-right pane set. | Varies with the particular combination. Examples: Substantively different categories at top level than at bottom level. Too many items or levels for tabbed panes alone or for a tree alone. |
To help you choose a navigation style, the following sections summarize these styles. Details of some styles come later in this chapter.
In the drill-down style, the content area shows the attributes of one item at a time, starting with the root "item" that contains the top-level list of items. The lower-level items are shown as links. The attributes of those lower-level items are revealed by clicking their links, which swaps the entire content area.
Parentage path and breadcrumbs (see 6.3 Breadcrumbs and Parentage Paths) are always present, both to show the context of the current page and to provide navigation besides the browser's simple Back action.
Drill-down style can handle an unlimited number of levels. However, in practice it is best suited to a small number. Here is an example of one level:
Here is an example of drilling into two levels:
Regarding proper titles on pages when breadcrumbs are used, follow the guidelines in 6.3 Breadcrumbs and Parentage Paths.
The items listed as links within the pages of the examples above are shown in flat lists. However, items can be displayed in a variety of other ways, such as a tree, a topology, or a collection of icons, as described in 5.1.6 Combinations of Navigation Styles.
Up to three levels of tabbed panes are permitted. Here are schematic examples of one, two, and three levels.
The style within each tabbed pane may be different, to suit each tabbed pane's contents. For example, one tabbed pane might contain a simple set of properties as fields, whereas another tabbed pane in the same set might contain a drill-down navigation style in a left-right pane set.
For details, see 5.2 Tabbed Panes Details.
One of the disadvantages of the tab-centric approach is that it sometimes requires quite a few clicks and drilling to get to particular parts of the UI. Though the tab-swapping method works from a usability standpoint, when it comes to managing deep and wide navigation hierarchies, it is beneficial to reduce the number of clicks and increase the stability of the visible navigation elements. The accordion allows users quick access to an application's top level objects and may offer a viable alternative solution. For details see <IP_ADDRESS> Accordion, below.
The Accordion component is a compact interface element, similar to a tabbed pane except that it is vertically oriented. As with clicking a tab, clicking on an accordion header (similar to a tab) reveals associated content.
The accordion allows users quick access to an application's top level objects. It provides an always-available, vertically-oriented, collapsible top-level navigation panel that would allow users to return to a "home base" in a single click no matter where they happened to be in the UI at the time. The accordion is comprised of containers which are mostly views or categories of objects rather than objects themselves. These containers help organize objects for easy access. The number of objects which can be represented is essentially unbounded, while it is possible to limit the number of categories. If navigation is over loaded with too many objects it will take a long time to load and a long time to read, thus reducing its value.
For details, see 5.2.5 Accordion Details.
In this navigation style, the left pane contains a list, tree, or other summary representation of items. The right pane shows the attributes of the single item that is currently focus-selected. Here is an example with a flat list in the left pane.
You can think of a flat list in the left pane as a set of tabbed panes turned on its side. Tabs run horizontally along the top of the page, whereas a left-pane list runs vertically along the side of the page.
Details are in section 5.3 Left-Right Pane Set Details.
Trees can show any number of levels. A tree with one level is just a flat list. Trees can be expandable and collapsible, but they can also be static. Trees often are presented in the left pane of a left-right pane set, but they need not be.
Details are in section 5.4 Tree Details.
Pop-up windows can be used as the detailed representations of objects whose summary representations are shown in the main browser window.
Clicking an object's summary representation (often a link) causes that object's attributes to appear in a pop-up window instead of by swapping all or part of the main window or a portion of the original window. (See the descriptions of other styles that use swapping, such as 5.1.1 Drill Down, 5.1.2 Tabbed Panes, 5.1.3 Left-Right Pane Set, and 5.1.6 Combinations of Navigation Styles.)
The pop-up window might be yet another window opened, in addition to any existing pop-up windows. This approach is useful for comparing objects, and for using one object as a source for changing another object. This approach also supports the user's mental model of each object being a concrete thing, because each object is shown in its own, concrete, physical window.
An example of using pop-up windows for top-level navigation is a single main window that shows only summary representations of all objects. A "summary representation" is a row in a table, or an icon, or some other minimal, summary representation of the object. That main window might use drill-down through container objects, or tabbed panes, or a tree, or some combination of them. It might even use a left-right pane set, but restrict the right pane to showing a read-only summary view of the focus-selected object. That main window is a stable, predictable, listing of the objects and a platform for operating on summarized objects. If that main window has a left-right pane set, it is also a convenient previewer of object properties. Sufficient space is available, because the innards of the objects appear in other windows. Also, that main window is stable, because opening objects does not disrupt it. Opening objects--seeing and editing all of their attributes--is done by selecting a summary representation's link name or icon. Then the object's attributes appear in a pop-up window, leaving the main window undisturbed.
If window management is a big problem in your UI, then you might not want to open yet another window for each object being opened. In that case, you might consider a compromise between opening a new window and drilling down: Devote a single pop-up window to all objects opened from the main window. Swap that one additional window's contents to show the most recently opened object.
Disadvantages of that compromise approach are the inability to compare objects, and only weak support for the mental model of objects as concrete things. A compromise a bit more toward the approach of all pop-up windows, is to devote one pop-up window to each type of object, instead of just one pop-up window for all object instances.
When opening objects into pop-up windows, make those pop-up windows contain secondary-content pages, not primary-content pages.
Primary and secondary-content pages are defined in 3.7 Primary-Content Pages and 3.8 Secondary-Content Pages, respectively.
There are many possible combinations of the drill down, tabbed panes, left-right pane set, tree, and pop-up windows styles. This section of the style guide describes just some of them.
Here are some guidelines for deciding how to combine those styles.
Use different styles for qualitatively different information.
For example, use tabbed panes for gross categories of objects. Then, within each tabbed pane, use a tree for the hierarchy of objects within that category.
Use tabbed panes for different representations of information.
For example, in one tabbed pane, put a tree. In another tabbed pane, put a flat list. In another tabbed pane, put a left-right pane set.
Note that this is an unusual style not commonly employed or strongly suggested for web-based applications.
Drill down in the left pane swaps the left pane with each drill down. A flat list (not a tree) appears below the left pane's parentage path.
Different UI elements are used in the left pane for drilling down versus for focus-selecting (to show properties in right pane). Those methods still require design work and will be fleshed out in more detail in a future version of this style guide.
This style provides the advantages of a left-right pane set when there are too many items or too many levels to use a tree in the left pane (<IP_ADDRESS> Tree In Left Pane). A tree can handle fewer levels when it is crammed into a left pane than when it has the full width of the window.
Drill down in the left pane is often more appropriate than a tree in the left pane, only when there are many levels in the hierarchy being shown in the left pane, or many items within levels in that hierarchy.
The existence of many levels in a tree causes the higher level labels to scroll out of sight to the left, when lower level labels are brought into sight. That's because the lower level labels are indented. Drill-down style reduces that problem by not indenting the higher level labels. Also, the higher level labels scroll out of sight to the top, because every level label consumes a row of vertical space. Drill-down style reduces that problem by concatenating all the higher level labels into breadcrumbs, consuming a single row. Even if the breadcrumbs wrap onto multiple rows, fewer rows are consumed than if each level label consumed an additional row.
The existence of many items within a level of a tree causes the higher level labels to scroll out of sight to the top, when items low on the list are brought into sight. That's because every level label consumes a row of vertical space. Drill-down style reduces that problem by concatenating all the higher level labels into breadcrumbs, consuming a single row. Even if the breadcrumbs wrap onto multiple rows, fewer rows are consumed than if each level label consumed an additional row. Fewer rows consumed by the level labels, leaves more rows to show the items, making items lower on the list visible without scrolling.
One product that uses this drill-down style is the StarOffice management user interface as of Spring 2003. That product's core design was derived by modifying Sun Identity Server 6.0's style (<IP_ADDRESS> Drill Down In Left Pane of a Tabbed Pane). Unlike Identity Server, StarOffice management didn't need multiple high-level categories of information and so didn't need tabbed panes at the top level.
If a tree won't fit in the left pane, then drill-down style can be used (section <IP_ADDRESS> Drill Down in Left Pane).
A tree can handle fewer levels when it is crammed into a left pane than when it has the full width of the window.
Here is a schematic of a tree in a one-level tabbed pane. However, it also can be used in two-level and three-level tabbed pane sets.
One good balance between tabbed panes and a tree, is to represent high-level categories of items as the tabbed panes, and, for each high-level item, the next-level set of items as a tree within the corresponding tabbed pane. In this case, in contrast to <IP_ADDRESS> Tree or Flat List in Left Pane of a Tabbed Pane, the tree is all by itself, it is not a left-pane navigational device controlling a right-pane; further navigation from the tree here would have to follow a drill-down navigation style.
For example, Identity Server 6.0 has several highest-level categories of items, each category drastically different from the others. One category contains items that are in a three-level tree that when fully expanded has at most 50 rows. So that category is represented as a tabbed pane containing a static tree. However, other categories are tabbed panes with other representations of their items--a left-pane drill-down style in one tabbed pane, a flat-list table in another.
If a tree won't vertically fit into a tabbed pane, then a drill-down style can be used instead of a tree (within the tabbed pane).
A tree can handle fewer items and levels when it is crammed into a vertically short area. A tabbed pane's content area is short because the tabs consume vertical space, especially when two or three levels of tabs exist. So a tree is less likely to fit vertically within a tabbed pane, than within a whole window not having tabbed panes.
This is the same as the regular tree in the left pane (<IP_ADDRESS> Tree in Left Pane), but the whole thing is nested in a tabbed pane.
Here is a tabbed pane containing a one-level tree (a flat list) in its left pane.
Here is a tabbed pane containing a tree in its left pane.
You might think of the left-right pane set as the last addition to the design. You could decide first to use tabbed panes, and second to use a tree. Then, when deciding how to show those tree items open, you might decide to use a left-right pane set because users need to switch quickly among items, spending little time on each item and moving quickly between items.
One good balance between tabbed panes and a tree, is to represent high-level categories of items as the tabbed panes, and, for each high-level item, the next-level set of items as a tree within the corresponding tabbed pane. In this case, in contrast to <IP_ADDRESS> Tree in Tabbed Pane, the tree is in the left-pane of a left-right frameset and as such, serves as the navigational device controlling what page gets loaded into the right-pane.
For example, Identity Server 6.0 has several highest-level categories of items, each category drastically different from the others. One category contains items that are in a three-level tree that when fully expanded has at most 50 rows. So that category is represented as a tabbed pane containing a left-right pane set, within the left pane there is a static tree. However, other categories are tabbed panes with other representations of their items--a left-pane drill-down style in one tabbed pane, a flat-list table in another.
If a tree won't fit into a left pane of a tabbed pane (vertically or horizontally), then a drill-down style can be used instead of a tree (within the tabbed pane). See <IP_ADDRESS> Drill Down in Left Pane of a Tabbed Pane.
A tree can handle fewer items and levels when it is crammed into a vertically short area. A tabbed pane's content area is short because the tabs consume vertical space, especially when two or three levels of tabs exist. A tree also can handle fewer levels when it is crammed into a left pane than when it has the full width of the window. A left pane in a tabbed pane imposes both those limitations--vertical and horizontal. (See detailed reasons in 5.1.4 Tree). So a tree is less likely to fit vertically and horizontally within the left pane in a tabbed pane, than within a whole window not having tabbed panes, or within a left pane that is not crammed into a tabbed pane.
Note that this is an unusual style not commonly employed or strongly suggested for web-based applications, like drill down in left pane in general.
This style combination is a fallback if you cannot use a tree in the left pane of a tabbed pane (see reasons in <IP_ADDRESS> Tree or Flat List in Left Pane of a Tabbed Pane).
This style is similar to drill down in the left pane (<IP_ADDRESS> Drill Down in Left Pane), but that whole combination of drill down in left pane is nested in a tabbed pane.
An example of a product that uses this style is Identity Server 6.0. That product has several highest-level categories of items. Each category is drastically different in the types of items it contains and in the representations that are appropriate. So each category is given its own tabbed pane. One category, represented by one of the tabbed panes, contains items that reside in a single, coherent hierarchy. A tree would be ideal to show that hierarchy within that tabbed pane, except that the hierarchy can have hundreds of levels and tens of thousands of items within each level, and the levels are heterogeneous in depth. That makes the tree too large, both vertically and horizontally, to fit into the left pane. None of the tree could be relegated to the right pane, because the right pane was reserved for the properties of the left pane's focus-selected item. So drill down was used instead of a tree.
5.1.7 Accordion
Tabbed panes navigation can be used when an application has a complex content area that requires a wide horizontal space. It might also be used when there is a small, fixed number of constant items or categories, which would not benefit from a tree and would suffer from a tree's complexities.
Use tabbed panes navigation for applications whose primary navigation categories can fit below the masthead without requiring horizontal scrolling. Take into account:
Here is an example of deciding between tabbed panes and a left-pane tree: Suppose the user is running the standard font size on a 1024 x 768 screen. A table can fit horizontally when it can consume an entire tabbed pane's width. However, the table would not fit if it had to be crammed into the right pane of a left-right pane set that had a tree in the left pane. In that case, tabbed panes might be the better approach. Otherwise, the page would have to scroll horizontally.
Another reason to use tabs is if the highest level of navigation represents a conceptually different dimension than the lower-level navigation does. For example, the lower-level navigation might be a hierarchy shown as a tree. A tree should not be embedded in another tree, so the higher-level navigation would be best represented as tabbed panes.
A situation where tabs should not be used is when considering this component for something other than navigation. Tabs are designed to be used only for navigation.
Do not use the selection of any one tab as a way to drive application logic by interpreting the tab selection as equivalent to the selection in a conventional data-entry element such as a set of radio buttons. Tabs are to be used for navigation (view-switching) only.
For example, if your application offers the user two alternative styles for performing some action, tabs should not be used to switch between the two UIs where the details are entered.
Instead, have the user manipulate a conventional data-entry element (for example, a radio button set) to establish which of the two alternatives the user wants to pursue, and then proceed to the page where the details are entered.
Typically, only two to six tabs can fit within each level of tabbed panes. However, that number might be larger or smaller, depending on the length and simplicity of the tab labels.
Do not use tabs if there is only one tab to show.
Showing a single tab is misleading since the tab element is designed to present multiple options to the user. Using the tab element for a single tab also uses screen real estate unnecessarily. Instead of showing a single tab, place the user interface elements that would be on the tab directly on the page.
Do not make the active tab a link.
The only effect of clicking a tab is to bring its attached pane to the foreground, but the active tab's pane is already in the foreground. Hovering over the active tab should not switch it to link appearance. Clicking on the active tab should not even reload the same page. Clicking on the active tab does absolutely nothing.
Make the leftmost tab the tab that users are most likely to access first, among all the tabs. Apply that guideline within each of the levels of tabs.
Do not use disabled tabs except in the following situations:
OR
Do not let tabs wrap to a second line. However, if a tab has a multi-word label and the width of the window is resized to a smaller size, the text of this multi-word label can wrap within the tab after the window resizing, if necessary.
Make the tab labels as short, yet as clear, as possible so that they do not wrap to multiple lines unnecessarily.
These tabs were not designed to be used with content area navigation tabs (see 6.4.2 Using Tabs for Content Area Navigation), because nonbrowser-based user interfaces typically avoid the use of nested tabs. However, this design possibility, along with others, is still being investigated for cases in which full screen width is important for an application's data, and a need exists for both top-level navigation through tabs and content area navigation when a drop-down menu is unsuitable.
Use headline capitalization (see 2.5 Text Capitalization) for all tab labels, both active and inactive.
Display a border beneath the inactive tabs, and along the sides and top of the active tab, such that the active tab appears to be part of the white page (or the background behind the next level of tabs) below it.
Do not have any border (line) below the active tab, or this visual association will be lost. If a line below the tab is unavoidable, such as when there is a frame break below it, leave a gap below the tab so that line sits below the whole control, and not near the line below the inactive tabs.
Do not let a row of tabs "wrap" to a second line. That is, there must never be some tabs of a level above others of that same level. However, the individual tabs can have their labels wrap to multiple lines within their "boxes", especially if the user resizes the window smaller.
Make all tabs, except the currently selected tab at each level, navigable by keyboard.
Keyboard navigation through all levels of tabs must be supported by allowing users to tab through the choices. The tab order is such that continuously pressing the Tab key moves the focus through the first-level row of tabs. Then, once a particular tab is selected, the Tab key moves the focus through the lower-level tabs within the selected tab. Tabbing to a first-level tab and pressing Enter shows the second-level tabs for that particular first-level tab. Tabbing to a second-level tab and pressing Enter shows the third-level tabs for that particular second-level tab.
In the same application, do not combine Tabs used for top-level navigation and Tabs used for content-area navigation. See 6.4.2 Using Tabs for Content Area Navigation for further details.
Except when tabs are used on a page with a Sun.com web site header (see 5.2.4 Tabs within a Sun.com Web Site Page and the Sun Web Site Design Standards), always have a gray background behind the row(s) of tabs, and continue it above them all the way up to the masthead, as shown below.
The HTML Title attribute of each tab, should consist of the tab label followed by the text " (Tab)".
For example, a tab whose visible label is "People," would have the HTML Title attribute "People (Tab)".
The word "Tab" is needed so that someone relying on the HTML Title attribute's text to be read by a text-to-speech reader or by a text-to-Braille reader will know what type of control ("Tab") has that label ("People").
For an interactive example of a Tab Control, see http://webdev2.sun.com/example/faces/tabset/navtab.jsp
A page can have one, two, or three levels of tabbed panes. The preceding guidelines apply to them all, but the guidelines in the next three sections are specific to those three levels.
This section's guidelines are sufficient for an individual tabbed pane that has only one level of tabs, when that tabbed pane exists within a set of tabbed panes all of whom also have only one level of tabs. Additional guidelines apply even to this one-level tabbed pane, when any other tabbed panes in its set have two or three levels. See 5.2.2 Two-Level Tabbed Panes and 5.2.3 Three-Level Tabbed Panes.
Here is an example of a one-level tabbed pane (the active tab, labeled "Jets") within a set of tabbed panes:
Put controls that affect an entire first-level set of tabbed panes, flush left above the tabs.
An example of this is a filtering control that affects the contents of all the tabbed panes in that set.
This section's guidelines are sufficient for a tabbed pane set that contains tabs with one or two levels of tabs. Additional guidelines apply if any of the tabs in that set have three levels. See 5.2.3 Three-Level Tabbed Panes.
The following is an example of a two-level tabbed pane. The active first-level tab is "AFC", and within it, the active second-level tab is "Jets".
When the user selects a first-level tab that has second-level tabs, there are two possibilities for which second-level tab is the default active tab. The default tab is either the leftmost tab or the most-recently-active tab. Which tab behavior occurs depends on which of three actions the user took:
If implementing the second-level tab selection behavior described in the preceding guideline is too onerous for your application, at least make the leftmost second-level tab the active tab whenever a first-level tab is clicked. However, you should resort to this fallback behavior only if absolutely necessary. The excuse that this implementation is "too onerous" is hard to justify.
The tab common component supports both the recommended behaviors (the prior guideline), and this fallback behavior.
Here is an example of a three-level tabbed pane. The active first-level tab is "Football", within it, the active second-level tab is "AFC", within it, the active third-level tab is "Jets".
Use three levels of tabs only when there is no other option. Three-level tabs have known usability problems, are visually complex, and consume a lot of vertical space. The disadvantages of using them typically outweighs the benefits, in most cases.
Apply the same guidelines as described in 5.2.2 Two-Level Tabbed Panes for determining the third-level default active tab.
When tabs are used on a page with a Sun.com web site header (see the Sun Web Site Design Standards), the gray background behind (visually above) the tabs should not be included, and a significant blank vertical gap should be left between the masthead and tabs, to look like this:
An accordion may be made of two or more accordion containers. Each container is comprised of an accordion Header and an accordion Body. The accordion header contains a label that distinctly identifies the contents of the accordion container and an optional turner icon. The text within the accordion header should be concise. If the text within the accordion header becomes too long to fit within the available space, it should wrap and the turner icon should align to the top. The accordion body contains the contents of the accordion container. The contents of the accordion body may include a table, a tree, a tab-set, etc.
The container header has three states:
Accordion containers may be opened or closed by clicking on the accordion headers. Clicking the accordion header of a closed accordion container opens the corresponding accordion body. Clicking the accordion header of an open accordion container closes the corresponding accordion body.
Based on how accordion containers are opened, there may be two versions of the accordion: the Single-Open Accordion and the Multiple-Open Accordion. If the user will need to refer to the contents of more than one accordion container at once, create a Multiple-Open Accordion. If not, use a single-open accordion, as it will be easier for the user to interact with.
The Single-Open Accordion will have only one accordion container open at a time, unless all containers are closed. When an accordion container is opened, any previously open container will automatically close. A container may be open by default when the application is launched, if desired, to support frequently performed tasks. The default open container may also be a preference setting that is user controlled. The following states are applicable to a Single-Open Accordion:
- The accordion may be fully closed - all accordion containers in the closed state
- Only one accordion container is open.
Multiple-Open Accordion
In a Multiple-Open Accordion, accordion containers may be opened or closed independent of each other. Opening an accordion container does not close any other open containers. If the length of the entire accordion exceeds the available height within the browser, a scrollbar will be provided to scroll down to content below the browser fold. The following states are applicable to a Multiple-Open Accordion:
- All accordion containers are closed
- All accordion containers are open
- One or more accordion containers are open, while the rest are closed.
Data within the accordion containers can either be preloaded when the application is launched or fetched as the user clicks on an accordion header. The accordion containers may also periodically fetch updated content asynchronously or users may explicitly refresh the containers using a refresh action. The refresh action may be a global action to refresh data within the entire accordion or one that allows users to refresh data individually for each accordion container. While content is refreshed within the accordion containers, a busy progress indicator indicates application activity. For information about busy indicators see 15.1.3 Busy Indicator. All actions available within the global header and the container header are disabled while the accordion container is in its busy state.
The accordion dimensions are absolute when dimensions are fixed (pixel units, ems), and liquid when they are a percentage of the parent container. The dimensions of the accordion may be either absolute or liquid in width, and separately may be either absolute or liquid in height. If the the dimensions of the accordion are absolute, then they will not change due to external factors like resizing of the browser window. If the accordion dimensions are liquid, the dimensions of the accordion should resize when either the browser window is resized or when users resize the left pane that contains the accordion.
Accordion Height
If the height of the accordion is liquid, scrolling is done inside individual containers. The overall accordion does not scroll.
If the height of the accordion is absolute, scrolling is done for the entire accordion, and no scrolling is done on individual containers.
Since Multiple-Open Accordions by nature will become quite tall, they should always be set to have absolute height.
Single-Open Accordions may be liquid or absolute in height. If the amount of content to be shown is large relative to the amount of available and visible height on the page, or at the opposite extreme if the accordion cannot ever become more than a minority percentage of the height of the page, using absolute height may make sense. Otherwise, having the height be liquid to fill the available and visible space on the page may make the most sense.
Accordion Width
The width of the accordion will initially be set to the percentage of the browser width or specified width. If the width of the accordion is liquid, horizontal resizing of the browser page will resize the accordion width accordingly. If the width of the accordion is absolute, however, the remainder of the page will change width while the accordion width remains unchanged.
Choose whether the accordion should have a liquid or absolute width based on whether the user may need to expand the page to see the full width of the content of the accordion. If the content width will almost always be short -- so need not be widened beyond the initially set size -- it is better to allow the extra browser space for the remainder of the page.
Left-right pane sets often use a tree in the left pane, but they can use any summary representations of objects. See 5.1.6 Combinations of Navigation Styles.
Often, the left and right panes are different frames, with a third frame for the masthead. However, a frameset is used only if the left pane is allowed to vertically scroll independently.
If scrolling the left pane is allowed, then allow scrolling in the right pane as well. Note that:
This layout creates an optimal out-of-the-box appearance, while allowing users who want to use large fonts to resize the frame accordingly.
Frame scrollbars and frame borders must not be suppressed- See 3.1 Main Browser Windows for detailed guidelines.
Achieve the default border appearances by not specifying any FRAMEBORDER or BORDER parameters within the FRAMESET and FRAME tags.
Many applications use a tree structure as the central organizing theme of their UI. This navigation tree is a complex UI control composed of numerous elements (application objects, labels, graphical elements, and links). Despite its complexity, you should think of the tree as a single control that has its own behavior, interaction requirements, and style.
Often, a tree is used in the left pane of a left-right pane set (see 5.1.6 Combinations of Navigation Styles). However, a tree can be used elsewhere.
The navigation tree enables users to view and navigate through a hierarchical arrangement of an application's objects. The tree component uses a number of elements to allow navigation through the hierarchy. They include:
Container-nodes can be further subdivided into:
The following example shows the various elements contained in a navigation tree:
Tree navigation is popular because it can be used to represent strict hierarchical relationships among objects, such as documents and folders. A strict hierarchy is relatively simple to represent with a tree because an instance of a particular object exists in one, and only one, place in the tree.
The complexity increases when trees are used for representing relationships among objects in more complicated applications such as certain system management applications. The strict, yet simple, "container/contained" hierarchical relationship that exists for documents and folders might not apply. Sometimes, these objects are members of multiple groups, which means that they could logically be contained in multiple container-nodes in the tree. However, the use of multiple representations of a particular object is potentially confusing to users, increasing the difficulty of learning the interface.
To the greatest extent possible, avoid using multiple representations of the same object in a tree.
If your application allows users to create their own groupings of nodes in the tree, do not prevent them from placing representations of an object in multiple places.
In this latter case, users are configuring their environment and might find it handy to have objects appear in multiple places in the tree.
For an interactive example of a Tree Control, see http://webdev2.sun.com/example/faces/tree/navTree.jsp
In most applications that use tree navigation, the leaf-nodes represent application objects (such as servers or users) instead of application actions (such as Add User or Delete User).
Whenever possible, represent application objects instead of application actions in the tree.
This design:
Never place application objects and actions in the same tree.
To present a clean, well-organized interface to users, navigation trees must contain only objects or only actions. Objects and actions must not be combined in the same tree.
A navigation tree can contain three types of container-nodes:
Include the root node in the tree only if users can select it (that is, when a user clicks on the root node, a page associated with the root node loads in the content area).
Do not include a navigation control for the root node. Instead, left-align its icon with the navigation controls for the nodes at the next level in the hierarchy.
This design saves horizontal real estate.
The distinction between folder-container-nodes and object-container-nodes is based on the function that the container-node performs in the application. The key question is whether the container-node represents a meaningful object in the context of the application itself, or if the container-node is only acting as a container. Thus:
For object-container-nodes in the tree, choose icons that represent their meaning or function.
The two types of container-nodes are visually distinguished by different icon styles, as follows:
A visual distinction is made between the two types of container-nodes because:
Show navigation controls (the iconic buttons used to expand and collapse the levels in a tree), only for container-nodes which have nodes at the next level of the hierarchy. Never include navigation controls if, upon clicking, no additional nodes are revealed.
Never show navigation controls for leaf nodes (nodes at the lowest level of a hierarchy).
This section of guidelines does not give a lot of details about the tree's appearance, because your tree will have the correct appearance as long as you use that common component (see Appendix A, Component Library Information).
Different subtleties in the appearance of the tree depend on its context of use. When used in the left pane of a left-right pane set, the tree has one of these four appearances:
Root node in the top shaded bar:
Tree title in the top shaded bar:
Actions drop-down menu in the top shaded bar:
When a tree appears in the Help window, it has a white background and no object icons (just
navigation control icons - the iconic buttons used to expand and collapse the levels in a tree):
A horizontal shaded bar must be at the top of a left pane that contains a tree, except when the tree appears in the Help window. That top shaded bar must never be empty. Its contents must be one of the following:
The Sun Common UI Component Library (in open source, the Project Woodstock components) (see Appendix A, Component Library Information) directly supports the tree appearance when the root node is displayed in the top shaded bar, as well as when the tree appears with a white background (for use in the Help window). To achieve the situations where a tree title or an action drop-down menu is displayed in the top shaded bar, you must add code to the existing component.
To indicate the currently selected node, bold the text of the node and shade the line that the node is on using a blue background color as shown.
Use bold for the most immediate visible ancestor of the selected node if the selected node is not visible because one of its ancestors is collapsed. Do not bold any ancestor of the selected node if the selected node is visible.
Use an icon for each node in the navigation tree except when a tree appears in the Help window. In the help window the only icons that are shown in the tree are navigation controls (the iconic buttons used to expand and collapse the levels in a tree).
Use a folder icon only for items that are pure containers, which serve only the function of containing objects.
When considering tree icons, use the appropriate tree icons as provided with the The Sun Common UI Component Library (in open source, the Project Woodstock components) (see Appendix A, Component Library Information).
The use of icons in the navigation tree is required (except in Help) because:
Indicate alarm states (or status states, but not both together) of tree objects with small "badges" that are superimposed over the lower right-hand corner of the object's icon. Propagate the states up the levels of the tree from the badged object's node, so that each parent node gets the highest-level badge of any of its children.
The following example shows a tree with badges superimposed on some of its icons. The Paducah and Building 1 objects are assigned the critical alarm badge because one of their descendants has that alarm badge. Likewise, Building 4 gets a warning alarm badge because one of its descendants has one.
For more information about the various alarm states, see 16.1 Alarms and Java Look and Feel Design Guidelines: Advanced Topics, specifically, chapter 8 Events and Alarms.
For more information about the various status indicators, see 16.2 Status.
Use the alarm and status icons provided in the Sun Common UI Component Library (in open source, the Project Woodstock components) (see Appendix A, Component Library Information). Follow the guidelines for creating badged alarm icons in Appendix G, Badging Icons.
Give a folder icon a badge only to reflect that its contained objects have badges. A folder icon cannot be alarmed just because the folder is empty or has an incorrect number of contained items, or contains an incorrect number of a particular type of item. Container items that do have such conditions must be represented by an icon other than a folder.
Tree nodes in the left pane of left-right pane style applications are yoked to links in the right pane. Yoking refers to behavior in which the left and right panes work as a single unit. Changing the selection in the tree changes which item's contents are displayed in the right pane. Likewise, changing which item is displayed in the right pane changes the selection in the navigation tree, regardless of how the change in the right pane occurred. This behavior closely matches the behavior of Java-technology based navigation trees.
In browser-based applications, yoking most likely results from clicking on a breadcrumb link or an object link in a table in the right pane. This yoking behavior uses a single-selection model, that is, only one item in the tree can be highlighted at a time.
Tree behavior must follow all the behaviors described in the following table. All described behaviors also apply to the help tree.
| Tree Object | Behavior of Tree Object When Clicked |
|---|---|
| Turner next to a collapsed container-node | Container-node should be expanded, but neither the current selection nor the content area should change. If the expansion reveals the (previously non-visible) selected node, bolding is removed from the selected node's most immediate visible ancestor and the selected node is given the selection highlight (bold text on blue background). If expansion reveals a more immediate ancestor of a non-visible selected node then the bolding moves to that ancestor. The content area does not change and is not refreshed. |
| Turner next to an expanded container-node | Container-node should be collapsed, but the content area should not change. If the selected node becomes invisible when its parent or an ancestor is collapsed, bold the most immediate visible ancestor of the selected node. If the parent of the current selection becomes invisible because one of its ancestors is the node that collapsed, then the most immediate ancestor that is not hidden by collapsed nodes should be bolded. The content area does not change and is not refreshed. |
| Icon or text of a node that is not already focus-selected | This node becomes the selected node and is given the selection highlight (bold text on blue background). The content area to the right is updated to show that node's view. If the node is a collapsed container node, the node is expanded. If the node is an already expanded container node, the node remains expanded. (The user must use the turners to collapse expanded nodes.) |
| Icon or text of the node that is already focus-selected | The selected node does not change. The content area does not change and is not refreshed. If the node is a collapsed container node, the node is expanded. If the node is an already expanded container node, the node remains expanded. (The user must use the turners to collapse expanded nodes.) |
| Link in content area (for example, breadcrumb link or link in table) | If the link is associated with a node in the tree, then that node should be made visible and given selection highlighting. If the node is located in one or more containers that are currently collapsed, then the containers should be expanded to reveal the node. If necessary, the tree should be scrolled to bring that node into view. If the previously selected node was not visible, the bolding of its most immediate ancestor should be removed, since the selected node will now be visible. |
The tree should be able to maintain its state (which object is selected, and which containers are expanded or collapsed) during refreshes, browser reloads, and updates to the tree.
This behavior is important because it helps maintain tree context. Users can become disoriented when their tree context is lost.
Scalability is one of the most challenging issues with applications containing lots of objects such as many system management applications. A system management application can contain large numbers of objects, so the UI needs to scale to maintain a consistent level of usability. Navigation trees enhance scalability because they enable users to quickly drill down and focus on the object, or set of objects, pertinent to the current task. Similarly, trees enable the hiding of objects that are not of current interest, thus reducing screen clutter.
However, the scalability of navigation trees has its limits, especially in a thin client, browser environment. As the number of nodes increases, trees can suffer from both horizontal and vertical scaling problems.
As the number of levels of depth in the tree increases, so does:
To maintain usability, design your application so that its navigation tree is no more than five levels deep.
If your application requires more levels of depth, consider some of the scaling methods described in <IP_ADDRESS> Scaling Methods for Trees.
Vertical scaling, which concerns the length of the tree, is also important to consider. As the number of objects in the tree increases, so does:
A vertical scaling problem can lead to both usability and performance problems. The performance decline varies, depending upon the particular implementation of the tree. Therefore, it is difficult to cite a recommended upper limit for the number of tree objects.
Design the tree so that the total number of potential objects does not unacceptably hinder load time or performance. If the tree takes a significantly long time to load, then you should consider whether the wait time is worth the benefit of using that particular design of the tree.
If your application needs to represent a large number of tree objects and encounters performance problems, see the following section.
If your application needs to represent a large number of objects in the tree, consider using one of the scaling methods described in this section.
Most of these scaling methods still need to be fleshed out and require additional design work. More detail may be provided in a future version of this style guide. For now, this section provides an overview of some available methods.
Note that these suggested solutions only apply to the Left-Right Pane Set class of navigation, where the left pane uses a tree. Other scenarios needing scalable trees are not covered by these suggestions.
One method that addresses both horizontal and vertical scaling involves presenting the lowest level of the object hierarchy in the content area instead of in the navigation tree. For example, instead of showing a node in the tree for each object representing a user, you could show a single node in the tree for "Users." Then, when the user clicks on it, you could display a table in the content area that contains all the User objects. These User objects could be links that enable users to drill down further in order to perform an action, such as viewing or editing User properties. This method is particularly useful when the number of objects is potentially very large, because it not only eliminates one level of depth in the tree, but can also significantly reduce the total number of tree objects.
If using the method described above does not solve your horizontal or vertical scrolling issues, there is another option that can be considered. This option is to display more than just the lowest level of the tree in the content area. Only a subset of the levels are shown in the tree; the remaining levels are shown in the right-hand side content area in a table. The objects below the lowest level shown in the tree are shown in a table, and the user navigates to lower levels by using drilldown and breadcrumbs/back buttons.
Only use the scalability strategies described above to the extent necessary for the data in your tree.
If a scalability strategy is needed, use the method whereby only the lowest level of the object hierarchy is moved out of the tree and into the content area, if this will suffice. Only use the method whereby multiple tree levels are moved out of the tree and into the content area if it is absolutely necessary for your data and scalability needs.
When multiple levels of the tree are moved into the content area, users can become lost because the tree seems to be abruptly, and perhaps arbitrarily, abandoned. In addition, the whole means of navigating through the data is changed, and the user must adjust to a second, rather different, navigation style without necessarily knowing why. Also, identification of the user's current location within the hierarchy requires looking at both the selection in the tree and looking at the breadcrumbs in the right pane.
If multiple levels of the tree are moved into the content area, choose a logical level to end tree navigation and to move to using the content area, if there is a logical breaking point available.
If a scalability strategy is needed, use one method consistently within your application.
Other scaling methods allow users to:
New Format for the remainder of this chapter
The format for the content comprising the remainder of this chapter has been done in the new format also shown in chapter 3. The new organization is a proposal for a standard way to present future chapters in the Web Application Guidelines. Some of the changes include:
R1, R2 ...
A1, A2 ...You can use Search in the masthead above to find a specific guideline in this chapter, e.g., 3.1R1.
Many Sun applications, as they exist today, are object-oriented (OO). This approach requires that users choose one or more objects and then apply an action to them. Another approach is to design the user interface to be task-oriented. In a task-oriented interface, users choose the task they want to perform. Then, in the context of performing that task, they choose the object(s) to which to apply the task.
To make existing OO applications into real task-oriented products would take a rebuild from the ground up, based on data from a thorough task analysis of prospective users. However, until products can be rebuilt, a good way to help the user of existing products is to provide a list of tasks and a set of wizards or other means to help perform those tasks. The list of the most common tasks is presented in what is called the Common Tasks page.
The design for the Common Tasks page should be different from other pages in the application (for visual uniqueness and identifiability). The goal is to provide users with quick access to tasks that are supported by key product features. When there are more than a few tasks, the page is divided into sections where functional groups of tasks are separated from each other. For example, functional groups might include configuration and troubleshooting.
These guidelines define four types of tasks:
Note: Only action-based and navigational tasks are currently specified.
If one task on the page is the task to view an overview of the product, mark that task with the Overview Marker, as shown in the picture above. This Overview Marker should not be used for any other purposes, and should appear at most once in any common tasks page.
In applications where a domain must be chosen and then tasks performed within that domain, separate those tasks into their own group, then have the selection control to choose the domain at the top of that group. The user can then select the domain and then do a set of tasks within that domain, or do global tasks from elsewhere on the page. This sort of selection is only appropriate for choosing a domain or logical subset of the data to act upon, however. Never have selection of a specific object within the common tasks page -- that selection should be done within the process of performing a task (or using actions upon a selected object within the standard object-oriented presentation).
For an interactive example of a Common Tasks Page, see http://webdev2.sun.com/example/faces/commontask/commonTasks.jsp
From a Preferences page, users can choose if they want the Common Tasks page to appear first when the application is started. This preference is optional, as well as the number of pages that appear in the list. Users can also choose which tasks to include on the Common Tasks page by selecting or deselecting checkboxes next to the tasks they want to see on the page. If a user does not have privileges to perform a certain task, the task should not appear on the Preferences page. (This also applies to disabled tasks.)
Use of the Preferences page can be extended beyond the scope of the Common Tasks page. If the Preferences page will be used across an application, the tasks included in the other sections of the preferences user interface should be global to the application (not specific to one page or task)
The layout of the Preferences page is similar to the Common Tasks page itself, with tasks grouped by function, as shown in this example:
The preferences page should be displayed as a pop-up window.
One Group of Common Tasks
If there is only one group of common tasks, that group should appear on the left side. If there is one group of tasks plus Preferences, the tasks remain on the left side of the page, with preferences at the bottom.
Two Groups of Common Tasks
When there are at least two groups of tasks, the second group should be placed on the right. Unless there is a logical order to the groups, the tasks should be ordered to balance the two columns as much as possible. If Preferences exist, they always appear at the bottom of the right column (once there are two columns):
Common Tasks That Don't Group Well
If there are any task groups on the page (other than Common Task Page Administration), all tasks must be inside groups. If necessary, put some of the the items in an "Other Tasks" group. This avoids confusion regarding whether tasks are in the group above them but just after a gap or etc.
However, if there are no task groups on the page (other than Common Task Page Administration), the tasks can be either placed in one group if a good name for that group exists, or placed outside any grouping. The latter can be done even if there is a group for Common Task Page Administration, as it will appear at the bottom and therefore can cause no confusion of items beneath it being within its group.
5.5.1 Access to the Common Tasks Page
Use guidelines in this section to provide users with easy access to the common tasks
page.
5.5.2 Navigational Tasks
Use guidelines in this section to enable the user to jump
directly from the common tasks page to where the task can be performed
in the application.
5.5.3 Action-Based Tasks
Use guidelines in this section to enable the user to alter the
state of the system by linking from a common task to either a
pop-up window or an inline wizard.
Hybrid tasks are currently FORBIDDEN because they are not compatible with one another. Hybrid tasks combine action and navigational tasks in a single task. The common task button label combines a verb and noun followed by the word and. A workaround is provided in the exception following 5.5.3 R2.
For example, start a server and show me its details -- FORBIDDEN
Multiple session tasks are not designed yet. They require interactions with steps that occur over extended periods of time: many hours or days and across sessions. Multiple session tasks are similar to action-based tasks, except the current wizard design does not apply. Future guideline releases may document these interactions.
| [ Table of Contents | 0 Revision History | 1 Introduction | 2 Visual Design | 3 Windows and Pages | 4 Mastheads | 5 Top-Level Navigation | 6 Content Area | 7 Simple Elements | 8 Complex Elements | 9 Tables | 10 Topology | 11 Contextual Help | 12 Search | 13 Wizards | 14 Alerts and Messages | 15 Progress Indicators | 16 Alarms and Status Indicators | 17 Login Page | 18 Version Page | Appendices ] |
| Privacy Policy | Terms of Use | Trademarks | Copyright 2007 Sun Microsystems, Inc. |


 %}
{% trans "Either the user has already taken the course, or the username of another user has been entered." %}


DOCTOR'S APPOINTMENT SCHEDULER
CATEGORY
DOCTORS
DOCTORS AVAILABILITY / APPOINTMENTS
Toggle
Toggle
CALENDAR
WAITING LIST
Drag and drop the below items
New
Delete
Id
Patient Name *
New Patient
Reason
From
To
Department
Consultant
Service
Repeat
Edit
Cancel
Submit
Cancel
Submit
ID
Name
Date of Birth
Mobile
Blood Group
Address
Cancel
Submit
Appointment Id:
Cancel
Submit
Are you sure want to delete this appointment?
Cancel
Ok
Your Appointment Id:
Appointment Booked
Ok
Doctor Name:
StartTime:
EndTime:


--- title: Portfolio ---
I am a quick-adapting Software Engineer passionate about disciplined development practices, automation, and lifelong learning of new technology. I have 6+ years professional experience in Web Development, API Development, E-Commerce, and more! I am strong believer in Open Source Software, and try to use it wherever possible.
While working as a Software Engineer at Rivian, I Created and deployed cloud-native Python REST APIs for the Rivian Digital Commerce platform—specifically in the products, pricing, and inventory domains.
I used tools such as AWS SQS, DynamoDB, and Lambda to create price authoring systems, dead letter queue (DLQ) aggregators, and more!
bearcycle combines fast-paced motorcycle racing with wacky platforming madness. This massive project, coded in the Godot Engine using C#, makes heavy use of hierarchical object-oriented design patterns. Each node is a finite state machine, governed by strict priority-based rules for transitioning between states.
There is also a cloud component to bearcycle. Users can create their own levels and share them with others around the world. This is accomplished via a REST API that authenticates a user, and interacts with AWS s3 bucket.
DemoWhile working as a Software Engineer at Esri, I was tasked with creating a "Map Widget" for use in Jupyter Notebooks. This widget allows users to run Python code that talks to the ArcGIS API for JavaScript, creating beautiful visualizations of spatial data in an interactive map.
This widget plays a crucial role in the spatial data science process—as you experiment with analytic Python code, you can visualize intermediate results in real time, adjusting your code as needed.
This Jekyll plugin allows you to embed dynamic Leaflet.js maps in static websites. You can use Liquid to pull the spatial data from posts, then draw points, polygons, geojson, etc.
I use this plugin for my personal travel blog, and it works quite nicely!
DemoShoot me a message to discuss technology, potential collaborations, or just to say hi!


About me
Hello! My name is Bruno, I'm from Brazil and I am a Front end Web Developer.
It took me a long time and some deviations to get here. I am a Law graduate, but by the end of the University, I already knew that I was not going to follow that path. So, when I finished it I decided to study business and got an MBA in it.
But again, I didn't feel in love. I liked it and I know that I will use a lot of things I learned there. But since it is a technology-oriented college, I started to see some devs working, and immediately I loved that.
Now, almost a year after I started learning to program, I am 100% confident that I made the right choice. I know that I have a long path to go, but I know that I found the thing that I want to do every day, and if I train, study and keep up myself updated on new technologies, I will achieve my goals.
This portfolio is all about that. I want to put my projects here and to use this as a playground to test new technologies and skills I learn. So don't expect this site to stay the same for a long time.
Below, there is my social media and my e-mail. If you have any tips/suggestions I would love to hear them, so don't hesitate in contacting me.
Welcome!