Progress bars are commonly displayed by graphical user interfaces for the purpose of indicating that some type of work is underway and is approaching completion. The type of work may vary greatly and may include: searching a database; opening a web page; downloading a file from a remote device; sending data to a printer; applying a transformation (such as color enhancement, resizing, or contrast adjustment) to a digital photograph; or sending/receiving email.
A progress bar may variously show how fast work is progressing, whether work is progressing, or the percentage of work that is complete or remaining.
Illustrative embodiments of the invention are illustrated in the drawings, in which:
The method 100 may be implemented by means of computer-readable code stored on computer-readable media. The computer-readable media may include, for example, any number or mixture of fixed or removable media (such as one or more fixed disks, random access memories (RAMs), read-only memories (ROMs), or compact discs), at either a single location or distributed over a network. The computer-readable code is executable by a computer, to cause the computer to perform the method 100. The computer-readable code will typically comprise software, but could also comprise firmware or a programmed circuit.
The display units 208, 210, 212, 214, 216 of the different progress bars 202, 204, 206 are preferably aligned, such that all of the display units 208, 214, 216 in a particular column correspond to a common work unit.
Each of the display units 208, 210, 212, 214, 216 may be color coded to indicate whether work was performed during a respective one of the work units. For example, in one embodiment, when no work is performed for a particular task part and work unit, a corresponding display unit is displayed in white, or in a color that blends into the background color of the GUI 200. However, when work is performed for a particular task part and work unit, a corresponding display unit is displayed in a non-white color (such as green).
Display units 208, 210, 212, 214, 216 may also be color-coded to indicate whether certain events occurred during particular work units. Or, the display units 208, 210, 212, 214, 216 may be colored to indicate whether or not an error was encountered during a particular work unit. The display units 208, 210, 212, 214, 216 may also be color coded to indicate how many errors were encountered during a particular work unit (such as: no errors, fewer than 50 errors, or more than 50 errors). Display units 208, 210, 212, 214, 216 may also be color coded to indicate, for example, a quality of the work performed for a particular task part during a particular work unit. Quality of work may be determined in various ways, and may depend on the type of work being done (such as a type of data being processed).
For the purpose of this description, black and white are considered colors that may be used to color code display units 208, 210, 212, 214, 216. Also, in addition to (or instead of) color coding, indications of work done, events, or errors, may be indicated via different patterns for the display units 208, 210, 212, 214, 216, or via changes in displayed icon types.
The task and task parts that are the subjects of the method 100 and GUI 200 may take various forms. In one embodiment, the task may be the processing of a plurality of messages corresponding to a packetized data transmission, and the task parts may comprise the processing of data pertaining to different logical protocol layers of the messages.
An H.223 header determines what kind of data (or payload) is contained in a frame. The data may be ITU-T H.245 control information (H.245), or part of an audio, video or data stream. Depending on the type of payload contained in a frame, the payload is processed as follows. If the payload is H.245 control information, the simple retransmission protocol (SRP) and channel segmentation and reassembly layer (CCSRL) headers for the control information are verified via CRC. If the CRC passes, the H.245 payload is decoded and used to determine: video and audio capabilities; the format being used to multiplex the audio, video, and data streams; or other information. If the payload in a frame is an audio, video or data stream defined by H.245, then an adaptation layer (AL) header is verified via CRC. If the header is good, the AL payload is concatenated with other data of the same stream, and the data is eventually assembled for playback (or saved).
The extraction and playing (or saving) of 3G-324M audio/video/data is a complex process and may involve the processing of a very large number of messages. Quite often, errors are detected in various protocols (e.g., via parity check or CRC). Erred frames are discarded, with the result being a minor or major effect on the reconstruction and playback of audio, video or data streams, depending on the frequency and positions of the errors.
In order to better communicate the progress of 3G-324M audio/video/data, and to indicate the frequency and position of error occurrences, the progress bars 302, 304, 306, 308, 310 shown in
The progress of each task part is indicated by a respective progress bar 302, 304, 306, 308, 310 comprised of a plurality of blocks 324, 326, 328, 330 (i.e., display units). Each block 324, 326, 328, 330 corresponds to a respective work unit, and each work unit corresponds to a substantially equal number of messages in a packetized data transmission. That is, the number of messages in a 3G-324M data transmission may be divided by the maximum number of blocks that are displayable in one of the progress bars 302, 304, 306, 308, 310, and the resultant number of messages is equivalent to one work unit (or display unit).
Each column of blocks (i.e., one block in each progress bar 302, 304, 306, 308, 310, such as blocks 328 and 330) indicate the work done during the execution of one work unit, and each row of blocks 324, 326, 328 indicates the work done (or progress) on a particular task part during a given work unit. White blocks 326 (which are bounded by black borders in the case of FP messages, and which are not bounded by any border in the case of other data types) indicate that no work was completed for a particular data type (or layer type) during a particular work unit. Green blocks 324 indicate that data was successfully processed for a particular layer type and work unit. Red blocks 330 indicate that an error was detected in at least one of the data payloads processed for a particular layer and work unit.
As shown in
In one embodiment, the GUI 300 shown in
As also shown in
Although
As another example, the GUI 200 could be adapted for use with a web browser. In such an application, different progress bars might indicate, for example, 1) the quantity, errors, retransmission attempts, and data rate of data transmitted to a website, 2) the quantity, errors, retransmission attempts, and data rate of data transmitted from a website, and 3) cookie activity.
Although the progress bars 202, 204, 206, 302, 304, 306, 308, 310 shown in
The method 100 and GUIs 200, 300 disclosed herein can be useful, in some cases, because they not only show the progress of an entire task, but they also show the progress of various parts of the task. The method 100 and GUIs 200, 300 can also be useful in that they can 1) give an overall view of the error count, quality, or number of events that are generated as work is being done, and 2) indicate the frequency and positions of errors or event occurrences.
This is a continuation of copending application Ser. No. 60/889,448 filed on Feb. 12, 2007, entitled “Method and Apparatus for an Improved Progress Monitor and Feedback During a Computer Process”, the entire disclosure of which is incorporated into this application by reference.
Number | Name | Date | Kind |
---|---|---|---|
4503499 | Mason et al. | Mar 1985 | A |
5301348 | Jaaskelainen | Apr 1994 | A |
6038588 | Nagarajayya et al. | Mar 2000 | A |
6115640 | Tarumi | Sep 2000 | A |
6480955 | DeKoning et al. | Nov 2002 | B1 |
6611276 | Muratori et al. | Aug 2003 | B1 |
6714827 | Brown et al. | Mar 2004 | B1 |
6901558 | Andreas et al. | May 2005 | B1 |
6934916 | Webb et al. | Aug 2005 | B1 |
6938214 | Proulx et al. | Aug 2005 | B2 |
6941522 | Brown | Sep 2005 | B2 |
7000193 | Impink et al. | Feb 2006 | B1 |
7594228 | Lam | Sep 2009 | B2 |
7607104 | Maeda | Oct 2009 | B2 |
20020077879 | Uchida et al. | Jun 2002 | A1 |
20030005022 | Brown | Jan 2003 | A1 |
20030194062 | Nelson et al. | Oct 2003 | A1 |
20030233162 | Kawai et al. | Dec 2003 | A1 |
20040148604 | Steffens et al. | Jul 2004 | A1 |
20050081200 | Rutten et al. | Apr 2005 | A1 |
20050102631 | Andreas et al. | May 2005 | A1 |
20050262148 | Davitt | Nov 2005 | A1 |
20060013555 | Poslinski | Jan 2006 | A1 |
20060044307 | Song | Mar 2006 | A1 |
20060212329 | Lucas et al. | Sep 2006 | A1 |
20060277487 | Poulsen et al. | Dec 2006 | A1 |
20070033624 | Oh | Feb 2007 | A1 |
20070143169 | Grant et al. | Jun 2007 | A1 |
20070143803 | Lim | Jun 2007 | A1 |
20070168861 | Bell et al. | Jul 2007 | A1 |
20070277122 | Frijlink et al. | Nov 2007 | A1 |
20070288292 | Gauger | Dec 2007 | A1 |
20080031595 | Cho | Feb 2008 | A1 |
20090094546 | Anzelde et al. | Apr 2009 | A1 |
20090247417 | Haas et al. | Oct 2009 | A1 |
Entry |
---|
German Patent and Trademark Office, Office Action dated May 5, 2009. |
Number | Date | Country | |
---|---|---|---|
20080195948 A1 | Aug 2008 | US |
Number | Date | Country | |
---|---|---|---|
60889448 | Feb 2007 | US |