Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Progress bar.
Nothing was collected or created yet.
Progress bar
View on Wikipediafrom Wikipedia
A progress bar is a graphical control element used to visualize the progression of an extended computer operation, such as a download, file transfer, or installation. Sometimes, the graphic is accompanied by a textual representation of the progress in a percent format. The concept can also be regarded to include "playback bars" in media players that keep track of the current location in the duration of a media file.
A more recent development is the indeterminate progress bar, which is used in situations where the extent of the task is unknown or the progress of the task cannot be determined in a way that could be expressed as a percentage. This bar uses motion or some other indicator (such as a barber's pole pattern) to show that progress is taking place, rather than using the size of the filled portion to show the total amount of progress, making it more like a throbber than a progress bar. There are also indeterminate progress indicators, which are not bar shaped.
History
[edit]The concept of a progress bar was invented before digital computing. In 1896 Karol Adamiecki developed a chart named a harmonogram, but better known today as a Gantt chart. Adamiecki did not publish his chart until 1931, however, and then only in Polish. The chart thus now bears the name of Henry Gantt (1861–1919), who designed his chart around the years 1910–1915 and popularized it in the west.
Adopting the concept to computing, the first graphical progress bar appeared in Mitchell Model's 1979 Ph. D. thesis, Monitoring System Behavior in a Complex Computational Environment.[1] In 1985, Brad Myers presented a paper on “percent-done progress indicators” at a conference on computer-human interactions.[2]
Perception
[edit]
Myers' research involved asking people to run database searches, some with a progress bar and some without. Those who waited whilst watching a progress bar described an overall more positive experience. Myers concluded that the use of a progress bar reduced anxiety and was more efficient.[3]
Typically, progress bars use a linear function, such that the advancement of a progress bar is directly proportional to the amount of work that has been completed. However, varying disk, memory, processor, bandwidth and other factors complicate this estimate. Consequently, progress bars often exhibit non-linear behaviors, such as acceleration, deceleration, and pauses. These behaviors, coupled with humans' non-linear perception of time passing, produces a variable perception of how long progress bars take to complete.[4] This also means that progress bars can be designed to "feel" faster.
Sometimes, to show the progress of a particularly long-taking operation such during program installation or when copying many files at once, applications resort to showing two progress bars at once, one for the operation as a whole, and the other to indicate the progress of identified sub-tasks such as the installation of a single component or the copying of an individual file.
Finally, the graphical design of progress bars has also been shown to influence humans' perception of duration.[5]
See also
[edit]
Wikimedia Commons has media related to Progress bar.
References
[edit]- ^ Model, Mitchell L., Monitoring System Behavior in a Complex Computational Environment, CSL-79-1, Xerox Corporation Palo Alto Research Center, 1979.
- ^ Myers, Brad A. "The importance of percent-done progress indicators for computer-human interfaces". In Proceedings of the SIGCHI conference on Human factors in computing systems. CHI '85. ACM, New York, NY. 11-17.
- ^ Daniel Engber "Who Made That Progress Bar?" [1].
- ^ Harrison, C., Amento, B., Kuznetsov, S., and Bell, R. 2007. "Rethinking the progress bar". In Proceedings of the 20th Annual ACM Symposium on User interface Software and Technology. UIST '07. ACM, New York, NY. 115-118.
- ^ Harrison, C., Yeo, Z., and Hudson, S. E. 2010. "Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations". In Proceedings of the 28th Annual SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY. 1545-1548.
Progress bar
View on Grokipediafrom Grokipedia
A progress bar is a graphical user interface (GUI) element that visually represents the status of an ongoing process, such as loading, downloading, or task completion, by filling a bar proportionally to indicate advancement toward 100% done.[1] These indicators originated in analog forms like early 20th-century Gantt charts for project management but transitioned to digital computing in the 1980s, with Brad Myers formally introducing percent-done progress bars at the 1985 CHI conference following the rise of GUIs like the Apple Macintosh in 1984.[2]
Progress bars serve critical roles in user experience by reassuring users that a system is active, reducing perceived wait times, and managing expectations during delays longer than 10 seconds, as supported by usability research showing users tolerate waits up to three times longer with visible progress feedback.[3] They come in two primary types: determinate bars, which display exact progress (e.g., 0–100%) for predictable tasks like file uploads, and indeterminate indicators, such as spinning spinners or throbbers, which signal ongoing activity without a specific timeline for shorter or variable processes.[3] Early digital implementations included text-based versions in UNIX systems using symbols like equals signs (=) or spinners (e.g., -, /, |, ), while graphical variants proliferated in the 1990s with web browsers like Netscape.[2]
Beyond functionality, progress bars have evolved aesthetically to incorporate motion, color, and shapes—like linear or circular designs with optional waves for expressiveness—to enhance engagement and accessibility, adhering to principles such as consistent sizing (e.g., 8dp track height) and high contrast for better visibility.[1] In modern applications, they extend to non-computational contexts, such as self-tracking apps and media interfaces, where they modulate user perceptions of time and effort, bridging human and machine temporalities.[2] Research continues to refine their design, emphasizing behaviors that minimize impatience, as explored in studies on duration perception and user satisfaction.[3]
Fundamentals
Definition and Purpose
A progress bar is a graphical control element used in user interfaces to visually represent the status of a task or process, typically depicting completion as a percentage or fraction of the total work.[4][5] It serves as an indicator that fills progressively, often in a linear or segmented format, to convey how much of an operation has been accomplished relative to the whole.[6] The primary purpose of a progress bar is to provide users with feedback during potentially lengthy operations, reducing uncertainty and perceived wait times by signaling ongoing system activity without requiring user intervention.[3] For instance, it is commonly employed in scenarios such as file downloads, software installations, or form submissions to inform users that their request is being processed and to set expectations for completion.[1] This feedback mechanism helps maintain user engagement and trust in the interface by demonstrating that the system is responsive, even if the exact duration remains variable.[7] At its core, a progress bar consists of a track, which forms the background outline or container, and an indicator, the filling element that advances to show progress.[6] Optional text labels may accompany these elements to display numerical percentages, estimated time remaining, or descriptive status updates, enhancing clarity for the user.[8] Progress bars originated as a digital adaptation of analog progress visualization techniques, translating physical or chart-based representations of task advancement into interactive computing elements.[9] They can be determinate, showing precise completion levels, or indeterminate, merely indicating activity without quantifiable metrics.[1]Types of Progress Bars
Progress bars are broadly classified into determinate and indeterminate types based on whether the duration or extent of a task can be accurately measured. Determinate progress bars provide a clear indication of completion progress, typically filling from empty to full as the task advances, allowing users to estimate remaining time. These are essential for tasks with known total steps, such as file downloads or software installations. Linear determinate progress bars, the most common variant, appear as horizontal or vertical bars that gradually fill with color or a progress indicator, often displaying a percentage or fraction (e.g., 50% complete). Horizontal versions are prevalent in desktop and mobile interfaces for sequential processes, while vertical ones suit space-constrained layouts like sidebars. Circular determinate progress bars, resembling a filling ring or arc, offer a compact alternative, commonly used in mobile apps for operations like photo processing where radial symmetry enhances visual appeal. Both linear and circular forms rely on smooth animations to convey continuity, with the filled portion representing the ratio of completed work to total work. In contrast, indeterminate progress bars signal ongoing activity without specifying completion progress, suitable for tasks with unpredictable durations, such as network requests or background computations. These often feature non-linear animations like spinning wheels, pulsing segments, or oscillating lines to imply motion without false precision. For instance, Google's Material Design guidelines recommend circular spinners for indeterminate states in Android apps, where a rotating arc provides a subtle cue of system busyness. Pulsing or dashed linear bars serve similar purposes in web interfaces, expanding and contracting to maintain user attention during waits. Stepped or segmented progress bars represent multi-stage processes by dividing the bar into discrete sections, highlighting the current step and completed ones. Each segment corresponds to a phase in workflows like user onboarding or multi-step forms (e.g., "Step 2 of 5 complete"), with visual markers such as filled circles or colored blocks at segment endpoints. This type excels in guiding users through linear sequences, such as e-commerce checkouts, by providing a roadmap of remaining stages. Other notable variants include radial progress bars styled like pie charts, which fill sector-by-sector to show proportional completion in circular formats, often seen in dashboard widgets for metrics like battery life. Skeletal progress bars act as animated placeholders in loading interfaces, mimicking the final layout with shimmering bars to set expectations during content rendering. Infinite loop animations, such as endlessly marching dots or waves, indicate perpetual tasks like real-time data streaming without implying an endpoint. Selection of a progress bar type depends on task predictability: determinate variants for measurable operations like uploads or renders, where accuracy builds trust, while indeterminate or segmented ones fit variable or phased activities to avoid misleading estimates.Historical Development
Precursors in Management Tools
The concept of progress visualization using graphical bars first emerged in the late 19th century with the harmonogram, invented by Polish engineer and economist Karol Adamiecki in 1896. This tool was developed to schedule and optimize production processes in steel mills and factories, employing a system of colored paper strips clamped to a board to represent tasks, with strip lengths proportional to time required and overlaps indicating dependencies. By allowing managers to rearrange strips dynamically, the harmonogram facilitated the harmonization of workflows, providing a visual means to track operational progress and resource allocation in industrial settings.[10][11] Building on this foundation, American mechanical engineer Henry Laurence Gantt refined and popularized bar charts for project management between 1910 and 1915, creating what are now known as Gantt charts. These diagrams used horizontal bars along a timeline to illustrate task sequences, durations, and interdependencies, with bar lengths denoting planned time and shaded portions showing actual progress completed. Gantt charts gained widespread adoption during World War I, particularly through their application by U.S. Army Chief of Ordnance General William Crozier to coordinate munitions production, enabling precise tracking of output against targets to support wartime logistics.[12][13][14] In manufacturing and logistics, both the harmonogram and Gantt charts served as essential instruments for visualizing workflow progress, helping to identify delays, balance workloads, and ensure proportional completion of production stages. Managers could quickly assess the status of multi-step processes—such as assembly lines or supply chains—through the intuitive scaling of bars, which translated abstract timelines into tangible representations without needing detailed textual reports. This approach established core principles of proportional progress indication that enhanced decision-making in resource-intensive environments.[10][15] These analog management tools provided the conceptual groundwork for computational adaptations, inspiring the integration of bar-based visualizations into software for monitoring task execution.[16]Emergence in Computing
The percent-done progress indicator, a foundational form of the modern progress bar, was invented in 1985 by Brad A. Myers, then a graduate student at Carnegie Mellon University. Myers developed this graphical element to alleviate user frustration during lengthy operations, such as slow database queries in early graphical user interfaces (GUIs), where users previously had no visual feedback on task completion. His work, presented at the ACM SIGCHI Conference on Human Factors in Computing Systems, emphasized empirical studies showing that such indicators reduced perceived wait times and improved user satisfaction by providing a clear sense of progress toward 100% completion.[9] Early adoption of progress indicators occurred in pioneering GUI systems, building on precursor visualization principles like digital Gantt charts from industrial management. The Xerox Star workstation, released in 1981, influenced subsequent designs through its emphasis on visual feedback in office automation tasks, though it featured rudimentary status indicators rather than full percent-done bars. The Apple Macintosh, introduced in 1984, used a wristwatch icon to indicate ongoing operations during file operations and application launches, enhancing usability in personal computing.[17] Myers further advanced their application in his Peridot system (1988), an interface-building tool at Carnegie Mellon that automatically generated percent-done progress indicators as standard widgets for demonstrated user interactions.[18][19] In the 1990s and 2000s, progress bars proliferated through standardization in major platforms and toolkits, driven by human-computer interaction (HCI) research advocating their role in reducing cognitive load during indeterminate waits. Microsoft introduced the ProgressBar control via the Win32 API's Common Controls library in 1996, bundled with Internet Explorer 3 for Windows 95, enabling developers to embed determinate and indeterminate bars in desktop applications. Web browsers followed suit, with Netscape Navigator incorporating download progress bars from its 1.0 release in 1994 to visualize page loading and file transfers. Animations enhanced these elements in cross-platform technologies, such as Java's JProgressBar in Swing (introduced 1998) for smooth indeterminate spinning and Flash's loading progress components (widely used from the early 2000s) for multimedia applications.[6][20][21] By the late 1990s, HCI advancements solidified progress bars as ubiquitous widgets in GUI toolkits, reflecting Myers' original vision of empirical usability testing. The Motif toolkit, a standard for Unix/X Window systems since 1990, incorporated progress-like scale widgets that evolved into full bars by Motif 2.0 (1995), promoting consistent interface design across enterprise software. Similarly, the Qt framework, released in 1995, included QProgressBar from version 2.0 (1999), facilitating animated and customizable implementations in cross-platform applications like KDE desktops. These integrations marked progress bars' transition from experimental HCI tools to essential components of digital interfaces.[22][23]Design Principles
Visual and Interaction Design
Visual elements in progress bar design play a crucial role in conveying status without overwhelming users. Color schemes typically employ neutral tones like blue for ongoing progress to indicate activity, transitioning to green upon completion to signal success.[24] Animation styles vary between smooth, continuous filling for determinate progress, which provides a sense of steady advancement, and discrete jumps or looping motions for indeterminate states to suggest ongoing activity without specific metrics.[3] Sizing is often proportional to the task's importance, with minimum dimensions such as 40dp for linear bars to ensure visibility, while larger scales up to 240dp accommodate prominent displays on expansive interfaces.[24] Interaction principles emphasize seamless user engagement during processes. Progress bars must respond promptly to updates, reflecting real-time changes to maintain trust in the system's accuracy.[25] Integration with accompanying text, such as "Uploading 75%," enhances clarity by combining visual and verbal cues for better comprehension.[3] Handling interruptions involves visual cues like pausing the animation on a resume button or displaying a stop indicator, such as a 4dp circle for linear determinate bars if the track contrast is less than 3:1 with the background, to meet contrast requirements.[24] Best practices advocate for alignment with established platform guidelines to foster familiarity. For instance, Material Design recommends linear bars with primary colors and optional wavy tracks for expressiveness, while ensuring animations avoid misleading perceptions by switching from indeterminate to determinate forms as data becomes available.[1] Scalability across screen sizes is achieved through adaptive sizing and right-to-left mirroring for diverse layouts, preventing distortion on mobile or desktop views.[24] Determinate and indeterminate forms differ in design application, with the former using percentage fills and the latter employing loops for unknown durations.[3] Representative examples illustrate these principles in context. Horizontal linear bars suit linear tasks like file downloads, filling left-to-right for intuitive progression.[24] Circular variants excel in space-constrained UIs, such as mobile notifications, where they center within buttons or cards to indicate loading without encroaching on limited real estate.[1]Accessibility Considerations
To ensure progress bars are accessible to users with disabilities, they must comply with Web Content Accessibility Guidelines (WCAG) Success Criterion 4.1.2 (Name, Role, Value) at Level A, which requires that all functionality, including progress indicators, exposes a programmatically determinable name, role, and value to assistive technologies.[26] For progress bars, this is achieved through WAI-ARIA attributes such as role="progressbar" to define the element's purpose, aria-valuenow to indicate the current progress (e.g., as a percentage), aria-valuemin (typically 0), and aria-valuemax (typically 100), enabling screen readers to announce updates like "progress 50 percent complete."[27] An accessible name, provided via aria-label or aria-labelledby, further describes the bar's context, such as "uploading file," to avoid ambiguity for users relying on screen readers.[26] Inclusive design features extend support to low-vision users by adhering to WCAG Success Criterion 1.4.11 (Non-text Contrast) at Level AA, mandating a minimum 3:1 contrast ratio between the progress bar's filled and unfilled portions, as well as against adjacent background colors, to ensure visibility without relying solely on color cues.[28] For keyboard users, while progress bars are typically non-interactive, any associated controls (e.g., cancel buttons) must be operable via keyboard per WCAG 2.1.1 (Keyboard) at Level A, with visible focus indicators. Non-visual alternatives include screen reader announcements for updates, and in some cases, audio cues or text-only modes via aria-live regions to convey progress without visual dependency, benefiting blind users who cannot perceive graphical changes.[29] Challenges arise with indeterminate progress bars, which lack a measurable value and cannot use aria-valuenow; instead, they should employ aria-busy="true" or an aria-live="polite" region announcing "in progress" or "loading" to inform users of ongoing activity without implying a false percentage.[30] Solutions involve testing with assistive technologies like Apple's VoiceOver on macOS, which verbalizes ARIA updates, and NVDA on Windows, which announces role and value changes, to verify announcements are timely and non-disruptive.[31] These tests ensure compliance and user comprehension, as improper implementation can leave screen reader users unaware of task status. The evolution of standards has enhanced dynamic announcements for progress bars through ARIA 1.2 (published 2023), which refines live region behaviors like aria-live to better broadcast changes without user focus, integrating with WCAG 2.1's 4.1.3 (Status Messages) for polite interruptions during long tasks.[32] This update supports more fluid experiences, such as intermittent progress reports, while prioritizing accessibility over purely visual aesthetics in color choices.[32]Implementation
In Desktop and Mobile Applications
In desktop applications, progress bars are implemented using platform-specific frameworks to provide native performance and integration. On Windows, the WinUI framework offers the ProgressBar control, which supports both determinate and indeterminate modes through the IsIndeterminate property; when set to true, it displays a repeating pattern to indicate ongoing activity without a specific percentage, while false enables value-based filling within a default range of 0 to 100.[33] For macOS, the Cocoa framework utilizes the NSProgressIndicator class, which operates in determinate mode to show task completion percentages or indeterminate mode to signal busyness without duration estimates.[34] In Linux environments, the GTK toolkit provides the GtkProgressBar widget, functioning in percentage mode via the gtk_progress_bar_set_fraction() method for determinate progress (values from 0.0 to 1.0) or activity mode with gtk_progress_bar_pulse() for indeterminate pulsing.[35] Mobile platforms adapt progress bars to touch interfaces and resource constraints. On iOS, SwiftUI's ProgressView supports determinate initialization with a bound numeric value (e.g., 0.0 to 1.0) for percentage tracking or indeterminate mode displaying spinning lines, with customizable styles like linear or circular.[36] Android employs the ProgressBar widget, available in horizontal style for determinate progress or spinner style for indeterminate indication, integrated into layouts for operations like data loading.[37] Platform differences necessitate considerations such as minimizing animation intensity on mobile to reduce battery drain, as progress bar animations activate the GPU from low-power states, increasing consumption during prolonged tasks.[38] Common implementation patterns across these platforms emphasize UI thread safety for updates, as direct manipulation from background threads can cause crashes or freezes; for instance, Android requires posting updates to the main thread via handlers, while WinUI and SwiftUI rely on dispatcher or actor mechanisms to marshal changes.[39] Time remaining estimates often employ algorithms based on average speed calculations, where recent progress rates (smoothed over iterations) divide remaining work to predict duration, avoiding volatility from initial slow starts.[40] Representative examples include file copy operations in Windows Explorer, which uses a determinate ProgressBar to track bytes transferred, and macOS Finder's NSProgressIndicator for similar disk operations.[33][34] App installations in the Apple App Store and Google Play Store display determinate progress views or bars, updating via platform APIs to reflect download and verification stages.[36][37]In Web Development
In web development, the HTML<progress> element provides a native way to represent determinate progress bars, where the completion status of a task is known. This semantic tag requires the max attribute to define the total amount of work (defaulting to 1 if omitted) and the value attribute to indicate the current progress, which must be a number between 0 and the max value. For example, <progress max="100" value="70"></progress> displays a bar filled to 70% of its maximum capacity.[4] For indeterminate progress, where the duration or completion is unknown, the <progress> element can be used without a value attribute in supporting browsers, though developers often fall back to custom <div> elements for greater control over appearance and behavior across environments.[41]
Styling progress bars with CSS allows customization of their visual appearance while maintaining semantic structure. For determinate bars, developers commonly use linear gradients to fill the progress indicator proportionally; for instance, targeting the ::-webkit-progress-value pseudo-element in WebKit-based browsers (Chrome, Safari) with background: linear-gradient(to right, #4caf50, #45a049); creates a smooth color transition for the filled portion. Vendor-specific pseudo-elements like ::-moz-progress-bar in Firefox enable similar gradient applications, while [Internet Explorer](/page/Internet Explorer) relies on the color property for basic fill styling. Indeterminate states are animated using CSS @keyframes, such as sliding stripes via background: linear-gradient(-45deg, transparent 33%, rgba(0,0,0,.1) 33%, rgba(0,0,0,.1) 66%, transparent 66%); background-size: 40px 40px; combined with animation: animate-stripes 5s linear infinite;, where the keyframe shifts the background position. These techniques ensure responsive, visually appealing bars but require vendor prefixes for broad compatibility.[41][42]
JavaScript enhances progress bars by dynamically updating them based on asynchronous operations, such as file uploads or data fetches. Using the XMLHttpRequest API, developers attach event listeners to the progress event on the request object or its upload property, accessing event.loaded and event.total to calculate and update the bar's value via DOM manipulation; for example, xhr.upload.addEventListener('progress', (e) => { progressBar.value = (e.loaded / e.total) * 100; });. This approach provides real-time feedback during AJAX requests. For more advanced visualizations like circular progress bars, libraries such as ProgressBar.js integrate seamlessly, leveraging SVG paths and the Shifty tweening engine for smooth animations driven by requestAnimationFrame; instantiation is straightforward, as in new ProgressBar.Circle(container, { strokeWidth: 4 }).animate(0.75);, supporting custom shapes and easing functions without heavy dependencies.[43][44]
Implementing progress bars in web applications presents challenges, particularly regarding cross-browser compatibility and performance. The <progress> element enjoys strong support in modern browsers—Chrome 8+, Firefox 6+, Safari 6+, Edge 12+, and Opera 11.5+—but lacks native rendering in Internet Explorer 6-9, necessitating JavaScript polyfills or fallback custom <div>-based bars with inline styles like <div style="width: 70%; background: green;"></div> inside the <progress> tag for graceful degradation. On low-end devices, CSS animations for indeterminate bars can strain resources if they trigger layout recalculations; optimization involves using GPU-accelerated properties like transform and opacity instead of width or background-position to maintain 60 FPS rendering, as recommended for mobile environments.[45][46][47]