The present application claims priority from chinese patent application filed at 2023, 11, 03 to the national intellectual property agency, application number 202311464467.7, application name "transaction management method and electronic device", the entire contents of which are incorporated herein by reference.
Detailed Description
Embodiments of the present application will be described below with reference to the accompanying drawings.
In the conventional scheme, management of reminder transactions is a decentralized management manner, and for ease of understanding, a specific example will be described below. Assuming that the user subscribes to the gaming activity at day 8, 30 for day 9, 3, 15, 00, the activity reminder is created (either from the gaming application or manually in the calendar application), i.e., a transaction is created that is "9, 3, 15, 00, to participate in the gaming activity", and the user later creates a reminder for the friend birthday at day 9, 3, 18, 00, beginning at day 9, 2 (i.e., creates a transaction "9, 3, 18, 00, to participate in the friend birthday"), but the user forgets to create a reminder for the net class entry for day 9, 3, 17, 00-19, 00 on day 8, 20 (i.e., creates a transaction of "net class entry for day 9, 3, 17, 00-19, 00"). In this example, since reminders are created in a decentralized manner, and transactions may be managed in a decentralized manner in different applications such as notes/memos, calendars, etc. after creation, it is difficult for a user to find conflicts that exist therein, and when the day comes for 9 months and 3 days, the user cannot know what things need to be done in total on the day, and cannot know what should be done before the day.
That is, the conventional scheme is that the creation and management of the transactions are performed in a scattered manner, so that the user cannot plan to coordinate all the transactions without missing the transactions because the reminder exists.
Aiming at the problems, the application provides a new transaction management method, and by intensively displaying all transactions of a whole day according to a time axis, namely, connecting all transactions of the whole day in series by using the time axis, the centralized management of all possible transactions from a time dimension is realized, so that a user can not only know what matters need to be done in total on the day of a target date, but also know what should be done first and then on the day, thereby enabling the user to plan the own whole day transaction better based on the matters. In addition, for the conflicting transactions, the conflicting transaction reminding card is displayed in the card display area, and the user can quickly position the conflicting transactions on the time axis through the conflicting transaction reminding card, so that the transactions are managed. In addition, whether these reminder transactions come from different applications or whether the creation dates are far apart, a series of problems that cannot be found in conventional schemes due to omission or conflicts in decentralized management are no longer present.
FIG. 1 is a schematic diagram of a transaction management interface according to an embodiment of the application. As shown in FIG. 1, a "My day" function may be added to the calendar application. After the user turns on the "My day" function, the electronic device may display a display interface of "My day". An example of a "my day" display interface is shown in fig. 1 (a) and 1 (c). It will be appreciated that the calendar application of FIG. 1 is an example of a follow-up calendar application, the interface of "My day" of FIG. 1 is an example of a transaction management interface, and the date corresponding to the My day of FIG. 1 is an example of a target date.
In FIG. 1, the calendar application is exemplified as including three functions of "calendar", "My day", and "proxy". The "calendar" in the function column corresponds to a month view interface, "my day" corresponds to a transaction management interface, and "agent" corresponds to a to-do management interface.
In fig. 1 (a) and 1 (c), the display interface is a management interface of the my day function, and if the user clicks on "calendar" in the function field in the display interface shown in fig. 1 (a), the month view interface is entered (switched to) as shown in fig. 1 (b). An example of a month view interface is shown in fig. 1 (b). Assuming that the user clicks on "my day" in the function bar in the month view interface shown in fig. 1 (b), the display interface is switched back from the month view interface to the display interface of "my day" (i.e., the transaction management interface).
In fig. 1 (a), the transaction management interface includes a card display area and a time axis display area, where the card display area is used to display at least one reminding card, which can be understood as a transaction that a user may need to pay attention to and manage, and the card display area is more striking and centralized to display in a card form, so that convenience is brought to user management. The card display area is mainly used for intensively displaying transactions meeting the management expectations of users, so the card display area can be also understood as a recommendation area for transaction management. The time axis display area displays cards of all transactions in series according to a time axis, so that a user can check and manage the cards conveniently from a time dimension.
The card presentation area may be arranged above (i.e., longitudinally spaced from) the timeline presentation area, such as shown in fig. 1 (a), with the card presentation area being located at the top of the timeline presentation area. For larger screen electronic devices, such as large screen folding screen cell phones, more content may be displayed due to the larger screen, the card presentation area and the timeline presentation area may be arranged side-to-side (i.e., distributed side-to-side), such as with the card presentation area on the left and the timeline presentation area on the right, such as shown in fig. 1 (c).
In one embodiment, assuming that the interface (an example of the first interface) shown in fig. 1 (b) is displayed after the calendar application is started, the interface (an example of the second interface) shown in fig. 1 (a) is displayed in response to the clicking operation (an example of the first operation) of the user on "my day" (an example of the first control) in the function field, and a third interface may be displayed in which a card that displays a transaction corresponding to the conflict transaction reminding card is located in the time axis display area in response to the second operation of the conflict transaction reminding card (an example of the at least one reminding card) in the card display area shown in fig. 1 (a) by the user.
The electronic device shown in fig. 1 may be various electronic devices such as a mobile phone, a tablet computer, a touch screen notebook computer, and the like, so long as the reminding and management of the transaction can be performed.
Details of the presentation and management of the card, and how the transaction is presented and managed are described in detail below with reference to the accompanying drawings. The following description will be made mainly taking the example that the card display area and the time axis display area are vertically distributed, and the card display area is located at the top of the time axis display area.
FIG. 2 is a schematic diagram of a transaction management interface according to an embodiment of the present application. Fig. 2 can be viewed as an example of the transaction management interface shown in fig. 1 (a). As shown in fig. 2, the card presentation area shows one travel reminder card. The travel reminding card comprises travel reminding, expected time and transaction content information and also comprises a navigation control, so that a user can start the map application to navigate by clicking the navigation control. However, it should be understood that the card display area is an area for intensively displaying some transactions recommended to the user for management, the travel reminding card is only one reminding card of various reminding cards, and other possible reminding cards will be described in detail below, and for brevity, the description is omitted here.
The timeline presentation area in fig. 2 includes two portions, an all day transaction portion and a time-slotted transaction portion. The time axis of the all day transaction part may use a dotted line, and the time axis of the time-division transaction reminding part may use a solid line. It should be appreciated that other forms of lines may be employed to distinguish between all day transaction portions and time-slotted transaction portions. On the time axis, the whole-day transaction part shows the transaction with the execution time period of one whole day or is understood as the transaction which can be done all the time in the day, so that the execution time of the transaction is not required to be limited as long as the user completes the transaction according to the actual situation. On the time axis, the time-slotted transaction reminder section shows that a transaction is not performed for a full day for a time slot, or is understood to require a particular time slot or point in time to be performed. The all day transactions in fig. 2 illustrate car maintenance and bank repayment, and the time-division transactions illustrate various transactions such as getting up, running outdoors, and the like. The start time of each transaction corresponds to a time start point on the time axis. Alternatively, it is understood that the time axis includes at least one time node, where each time node corresponds to a transaction, and the time node may be a time starting point of each transaction. Each transaction may include a transaction name, an application source in the card of the timeline presentation area. Icons or interfaces (examples of jump controls) that can jump to other applications may also be included in the cards of the timeline presentation area, for example, an "8:14 high-speed rail travel" transaction can jump to a map application through the map application icon in the transaction card.
It should be understood that the cards on the time axis, each card corresponding to a transaction, can be understood that the cards on the time axis show the relevant information of the transaction, and each card shows the relevant information of a transaction. The cards in the card display area are displayed in a centralized manner according to the management expectations of the user, and the transactions which are not on the time axis are displayed in a supplementary manner. As described above, the card presentation area may be considered a recommendation area that best meets the user's expectations for the transaction to be managed. The special day reminding card is a reminding card in which no corresponding transaction card exists in the time axis display area.
It is also shown in fig. 2 that the time axis can be distinguished in different colors for the time that has elapsed and the time that has not arrived. Assuming that the user entered the "my day" interface on the day of the target date, it can be seen from the top right corner time in the interface shown in fig. 2 that now is 7:15, that is, the user opened "my day" in the calendar application on 7:15 on the day of the target date, and seen the timeline color distribution case shown in fig. 2, the time before 7:15 is the time that has elapsed, the timeline is displayed in black (one example of the first color), the time after 7:15 is less than the time, and the timeline is displayed in blue (one example of the second color). It should be understood that as long as the elapsed time and the time that has not arrived are distinguished by different colors, there is no limitation as to what color is specifically used, respectively. However, the time which has elapsed is black or gray, and the time which does not come is colored, so that the time axis which does not come is relatively striking, and the use requirement of a user is more satisfied.
Fig. 2 is an example of 7:15 entry into "my day" on the day of the target date, but it should be understood that the user may enter "my day" at any time within the target date, without limitation. And the display content in the display interface will be different due to the different time of entering the interface. For example, assuming that the user entered the "my day" interface shown in FIG. 2 on the day 12:00 of the target date, the immediately starting travel reminder card for the card presentation area in FIG. 2 disappeared, the 12:00 preceding time axis was black, the 12:00 following time axis was blue, and other possible display differences were not listed one by one. In short, a user entering "My day" at different times will see different displays.
It should be understood that, in addition to differentiating the elapsed time and the unreachable time on the time axis by using different colors, the differentiation may be performed by using the thickness of the line, for example, the line of the time axis corresponding to the elapsed time may be thin and the line of the time axis corresponding to the unreachable time may be thick. In addition, the two different coaxial line states can be set for distinguishing, for example, the thickness and the color of the line can be integrated, that is, the two distinguishing schemes are overlapped, and the like. That is, the embodiment of the present application also does not limit the specific display form (e.g., position, size, shape) of the time axis in the time axis display area. The setting may be made based on a principle that the time axis portion corresponding to the time of the short arrival is more conspicuous in consideration of the usage habit of the user.
Fig. 3 is a schematic diagram of a time axis display area according to an embodiment of the present application. Fig. 3 can be seen as an example of the timeline presentation area in fig. 2.
As shown in fig. 3, the time axis of the all-day transaction portion (all-day period) is exemplified by a broken line, and the time axis of the time-division transaction portion is exemplified by a solid line. In fig. 3, the "car maintenance" transaction is an all-day transaction, which is a local calendar, and the "XX bank repayment date" transaction is an all-day transaction, which is obtained from a short message application by means of short message identification, and is an all-day backlog. When the all-day backlog has been completed, the control of whether the all-day backlog is completed may be marked as completed (i.e., marked with a tick in the circle in FIG. 3). The backlog completed can be marked by deleting lines, so that the backlog is more striking, and a user can know that the backlog is not needed to be processed.
It should be noted that, in the embodiment of the present application, a transaction may be understood as a thing that a user needs to do, where a transaction often needs to include what to do (content of the transaction), what to do (location), how to do (processing manner), when to do (execution time), and so on. The transactions may include schedules and backlog. Scheduling can also be understood as a scheduling, often requiring something to be done at what time and at what particular place. Backlog is to record what is not yet done, and backlog does not necessarily have strict time and place restrictions, and may only need to be done before a certain time node. In connection with fig. 3, "XX bank payoff day" is a backlog that may be accomplished by performing some operations on the electronic device, rather than having to go to a specific location at a specific time. "check-in to a hotel" is a schedule, which requires a specific place to check-in to the hotel at a specific time period of 12:00-13:00, so the card of the schedule also includes a detailed address column for indicating the place for the user to execute. The "A oral registration" is a backlog, although a specific execution time is agreed, namely, after 12:00, no appointed place exists, and although the "A oral registration" is a specific place, the registration does not necessarily need to go to the site for registration, and the electronic equipment side can also operate for online registration (remote registration). It can be seen that backlog and schedule are not very strictly defined, but all transactions are divided into schedule and backlog according to certain characteristics, so that the management of users is facilitated. In some cases, it may also be understood that a schedule is created when a user creates a transaction, where the transaction type is a schedule, and a backlog is created when a user creates a transaction, where the transaction type is a backlog. The schedule is more dependent on both time and place attributes.
As described above, transactions may be divided into all day transactions and time period transactions according to whether the execution time period is all days, and may be divided into schedules and backlogs according to the type and/or the degree of dependency on the place of time when the transactions were created. That is, the transactions can be divided into different categories according to different division bases, so that classification display and management are convenient. The two classifications may be stacked. For example, "XX Bank payoff day" in FIG. 3 is a backlog, and is also an all-day transaction, and may be referred to as an all-day backlog.
As also shown in FIG. 3, the time-slotted transaction reminder portion may begin with a 6:00 am start transaction. The 6:00 am start transaction comes from an alarm clock application (or clock application) that includes the system source identification, i.e., an identification that indicates that the transaction comes from the system application-clock.
7:00, An outdoor running business, is a schedule, is from an exercise health application, is an exercise program synchronized by the exercise health application, and also displays synchronized moving objects in a card of the business. In the example shown in FIG. 3, clicking on the source identifier for running health does not jump to the example. Because the information displayed in the sports health needs is not much, the content displayed in the card can basically meet the needs of users, and whether to establish a jump link to jump to the sports health application can be guaranteed. If the jump link is set, more synchronous design on the background process is needed to be completed, and if the jump link is not set, the subsequent synchronous design is not needed.
The ' 12306 ' 11A-Nanjing south station G7271 ' corresponding to 8:14-9:14 is a high-speed rail travel transaction, is a schedule, and comprises information such as time periods (8:14-9:14), places (Shanghai rainbow bridge stations), start and stop stations (Shanghai 11A and Nanjing south stations) and the like of the schedule, wherein the transaction is derived from a short message application and is obtained through identification of short message content. The card of the schedule also comprises an icon (an example of a jump control) of the map application, which can be regarded as a control in the card of the schedule, and clicking the icon of the map application can open the map application (an example of a first application) to start navigation. After clicking on the icon of the map application, it may be in one case that the map application is launched and the home page of the map application is displayed (an example of the fourth interface). In another case, it may be that the map application is started to display a navigation page (another example of the fourth interface) of the map application, and address information is loaded (filled in) in the navigation page, for example, "Shanghai iridescent bridge station" may be filled in a destination column. It should be appreciated that both of the above scenarios may be implemented, and that whichever is specifically employed may be provided on the electronic device as desired. The first or second type may be selected if the map application allows direct cross-application writing of data, and the first type may be selected if the map application does not allow direct cross-application writing of data.
As shown in fig. 3, an example of a care is given at noon, "rest, full energy. In one example, a time threshold may be set for a care phrase that is displayed when a time interval between an end time of a last schedule of a morning period and a start time of a first schedule of a afternoon period is greater than or equal to the care phrase preset time threshold, otherwise, no care phrase is displayed. The time threshold may be, for example, two hours. As shown in connection with fig. 3, a care may be displayed between a card of a high-speed rail travel transaction of 8:14-9:14 and a card of a hotel check-in transaction of 12:00-13:00 at an end time of 9:14, a start time of a hotel check-in transaction of 12:00, and a difference time of more than two hours.
As shown in FIG. 3, 12:00-13:00 have a "check-in to a hotel" transaction, which is a schedule, from a SMS application. 12:00 also starts an "A oral registration" transaction, which is a backlog from a living application.
An example of a 12:00 start two transaction time conflict is given in FIG. 3. In connection with fig. 2, the conflict will generate a conflict reminding card, which is displayed in the card display area to more prominently remind the user to manage the transaction with the conflict. Specific management methods will be described below, and are not described here again.
Also shown in FIG. 3 is the "Cooperation with XX company" transaction of 16:00-18:00 pm, which is a schedule, from third party application "office application #1", and the card of which also includes a link icon (an example of a jump control) that can jump to the video conferencing interface in office application #1, and can complete the jump by clicking.
Also shown in fig. 3 is a new on-chip reminder transaction of 20:30-21:30 evening, which is a backlog, and video application #2 (which is an example of a third party application, a first application) can be opened for new viewing by clicking on a link (an example of a jump control).
As shown in fig. 3, the time axis before 16:00 is gray, and the time axis after 16:00 is colored (here, blue), that is, the actual time corresponding to fig. 3 is before 16:00. In this example, the time axis corresponding to the time that has elapsed shows gray, and the time axis corresponding to the time that has not yet arrived shows blue.
Assuming that the color update of the time axis is updated at the start time of a transaction, that is, the time axis of a transaction before the time node of the time axis is set to gray every time the start time of a transaction is reached, the time axis after the time node remains colored. Assuming that the color update of the time axis is updated at the end time of a transaction, that is, the time axis before the end time on the time axis is set to gray every time the end time of a certain transaction is reached, the time axis after the time node remains colored. In connection with fig. 3, it is assumed that the color of the time axis is updated in the first way, i.e. at the start time of the transaction, that the real time (actual time) corresponding to fig. 3 is after 12:00 and before 16:00, and that the color of the time axis is updated in the second way, i.e. at the end time of the transaction, that the real time (actual time) corresponding to fig. 3 is after 13:00 and before 16:00. Furthermore, since some transactions are not explicitly ending in time, there may be cases where the ending time of a previous transaction is after the starting time of a subsequent transaction for a conflicting transaction, it may be relatively difficult to update the color by ending time, which may be the case by first updating by the starting time of the transaction when the transaction has no ending time.
In one example, when the user enters the "my day" interface, the current time (actual time) may be obtained, and the transaction whose time is closest to the current time on the time axis is determined according to the current time, and is the transaction that has not yet started, all time axes before the transaction are set to black or gray, and all time axes after the transaction are colored.
As can be seen from fig. 3, the transactions are connected in series on a time axis, and the transactions can be either a schedule or backlog, and can also be jumped to other applications through a set jump control.
Assuming that the user clicks on the clock small icon (an example of a folding control) on the time axis for the several periods of morning, noon, afternoon and evening in fig. 3, all transactions for the corresponding period can be folded. For example, clicking on a small clock icon on the "am" timeline will collapse three transactions of getting up, running outdoors, and going out on a high-speed rail. Suppose that the user clicks on the small clock icon on the "noon" timeline, which will collapse both a hotel check-in and an a-slot registration. Other cases are not listed one by one.
Instead of the manual folding method, an automatic folding method can be adopted. In the automatic folding manner, a period of time that has ended before the time may be automatically folded based on the time when the user entered the transaction management interface. For example, assuming the user is entering the transaction management interface at 14:00, all transactions during the "morning" period may be automatically collapsed. Furthermore, the time period may be divided into a plurality of time periods as needed, for example, four time periods of morning, noon, afternoon and evening in fig. 3, and three time periods of morning, afternoon and evening are illustrated in fig. 4.
Fig. 4 is a schematic diagram of a setting method of folding or unfolding a calendar according to an embodiment of the present application. Assume that an entire day is divided into three time periods, i.e., morning, afternoon, and evening, as shown in fig. 4, which is the result of manual folding of both the three time periods and the time period of the whole day transaction. All-day transactions are folded to hide cards of 2 transactions, are folded to hide cards of 3 transactions in the morning, are folded to hide cards of 2 transactions in the afternoon, and are folded to hide cards of 1 transaction in the evening. Assuming that the user clicks the expand control for a certain period, the cards of all transactions under that period can be expanded, i.e., the cards hidden by the fold are redisplayed on the interface.
Assuming the case of automatic folding, automatic folding can be performed for a period of time that has ended. However, it should be appreciated that in this example, the all day transaction portion is automatically collapsed unless it is the entire day that ends all the time, because the corresponding time period is all day, i.e., the user entering the "my day" interface on any time of the day on the target date will not see the all day transaction portion being automatically collapsed.
Fig. 5 is a schematic diagram of a case of automatically positioning display according to the current time according to an embodiment of the present application. As shown in fig. 5, assuming that the current time is 20:20 of the evening of the current day of the target date, after the user enters the my day function, the electronic device will completely display the card of the transaction corresponding to the current time in the time axis display area, and in combination with fig. 5, automatically locate the card of the new online transaction of 20:30-21:30 to complete. The transaction corresponding to the current time may be the transaction closest to the current time but not yet reaching its start time. With reference to fig. 2 and fig. 5, assuming that the user enters the my day interface at 7:15 (an example of the first time), the current time on the positioning time axis is 7:15, the corresponding transaction is the high-speed rail travel transaction of 8:14-9:14 (an example of the fifth transaction), the positioning display is to completely display the card of the high-speed rail travel transaction of 8:14-9:14, if the card of the transaction is already in the display interface, no action is performed, and if a part of the card of the transaction is or is not at all in the display interface, the positioning display is to completely display the card of the transaction which is not originally in the display interface into the display interface. Assuming the user entered the interface of "My day" at 20:20 (an example of the second time), and assuming the initial interface after entry was as shown in FIG. 2, the timeline would not be able to fully display the transaction after 20:20, then the card for the last transaction "new on-chip" transaction (an example of the sixth transaction) after 20:20 would be displayed fully on the display interface by positioning the display, as shown in FIG. 5.
In addition to the change in display content in the display interface caused by positioning display, the change in entry time also causes the change in display content, the automatic management policy for cards that have passed the time period also causes the change in display content, and if some operations for managing cards are performed by the user before the current time, the change in display content is also caused. So as shown in fig. 5, in addition to the variation of the cards of the time axis display area from fig. 2, the color distribution on the time axis also varies from fig. 2, and the cards displayed in the card display area in fig. 5 also varies from fig. 2.
For the elapsed time period, fig. 5 exemplifies that the time axis is set to gray but the card of the time axis display area of the elapsed time period on the time axis is not set to gray. When all of the target dates have ended, the cards for all transactions may be set to gray.
Fig. 6 is a schematic design diagram of a schedule style and a backlog style according to an embodiment of the present application. As shown in fig. 6 (a), the schedule includes a title (which may be set to display only one line or two lines at maximum in order to prevent the title from excessively long resulting in a too large display area), an execution period (the execution period is not required if it is an all-day transaction, only a divided period transaction is required to display the execution period), a place, and an application source (from which application).
As shown in FIG. 6 (b), the schedule may also include an operation button (which may be a jump link or a start link for jumping to the relevant page of the relevant application).
As shown in FIG. 6 (c), the schedule may also include a system application source icon to more prominently show from which system application the schedule came.
As shown in fig. 6 (d), the backlog includes a title (which may be set to display only one line or two lines at maximum in order to prevent the title from excessively long resulting in a too large display area), an execution period (the execution period is not required if it is an all-day transaction, and only a divided period transaction is required to display the execution period), and an application source (from which application). In contrast to a schedule, backlog has no place, and a display place is not required because backlogs such as car washes, shopping, repayment, etc. do not always need to go to a specific place. Such as telephone charge, life payment, etc., are not related to a specific location at all.
As shown in fig. 6 (e), the backlog may further include a flag indicating whether the hooking is completed, and a blank circle is not completed. It should be appreciated that other ways of marking completion may also be employed.
It should also be appreciated that a transaction will be displayed as a schedule or to-do during "my day," whether the transaction type created at the time of the user creation of the transaction is a schedule or to-do, or whether the transaction type is determined based on conditions such as whether the location can be identified during the smart identification process. For example, assume that a user creates a schedule when creating a business, and even if the schedule does not have a place of remark, the schedule is displayed as a schedule in "my day", and assume that a user creates a to-do when creating a business, and even if the to-do has a place of remark, the schedule is displayed as a to-do in "my day". Assuming that the source of the transaction is obtained through intelligent recognition from other applications, such as the sms recognition of fig. 2-5, the transaction category may be determined based on whether the content requirements of the schedule or to-do are met. The schedule may be created assuming that the title, execution time period, location and application source (in this case, the application source is a short message application) can be identified based on the short message identification, and the backlog may be created assuming that the title, execution time period and application source can be identified based on the short message identification but the location cannot be identified.
The transaction type may be determined based on whether the transaction type created at the time of creating the transaction by the user is the all-day transaction or the time-divided transaction, or based on whether the specific time period can be identified in the smart identification process, similar to the above. By way of example, assume that a user creates a full day transaction, which is shown as a full day transaction in "my day", and a time-of-day transaction, which is shown as a time-of-day transaction in "my day". Assuming that the source of the transaction is obtained through intelligent recognition from other applications, such as the sms recognition of fig. 2-5, the transaction category may be determined based on whether a specific time period exists. It is assumed that the execution time period, that is, the time-divided transaction, can be identified based on the sms identification, and otherwise, the all-day transaction.
FIG. 7 is a schematic diagram of an execution process for managing schedules according to an embodiment of the present application. In fig. 7, the management of a hotel check-in transaction of 12:00-13:00 in fig. 3 is taken as an example, and the management of other schedule type transactions is similar and will not be repeated. As shown in fig. 7 (a), the user can perform a sliding operation on the card of the transaction on the time axis. Taking the left slide as an example here, in response to the sliding operation, the electronic device may display the management control shown in fig. 7 (b), taking the management control as an example including an important transaction tagging control, an ignore alert control, and a delete transaction control. Assuming that the user clicks the important transaction flag control in fig. 7 (b), in response to the clicking operation, the electronic device displays a small flag color change in the control shown in fig. 7 (c) to indicate that the control is selected (i.e., that the important transaction and the non-important transaction can be distinguished by such a colored small flag as a flag), then in the case that the user does not perform other interactive operations, the electronic device displays an important transaction flag added to the transaction card shown in fig. 7 (d), where the important transaction flag is a red small flag to indicate that the transaction is an important transaction. As can be seen by comparing fig. 7 (a) with fig. 7 (d), the normal transaction (non-important transaction) has no small flag, and the important transaction includes a small flag with a color (which can be seen as an example of an important transaction flag).
Fig. 7 (a) - (d) show examples of an interactive process of setting the status of a schedule type transaction as an important transaction, and important transactions and non-important transactions may be distinguished by marking.
Assuming that the user clicks the ignore alert control in fig. 7 (b), in response to the user clicking the ignore alert control, the electronic device displays the situation shown in fig. 7 (e), changes the transaction to a mode of abbreviated display, that is, detailed information such as time and place is not displayed any more, only the title is displayed, and the title is gray. However, it should be understood that, in practice, it is only convenient for the user to distinguish whether the transaction is ignored or not, and other manners of displaying the ignored transaction may be adopted.
Fig. 7 (a), (b), and (e) show examples of an interactive process in which the status of schedule-type transactions is set to ignore reminder transactions, and ignored transactions can be distinguished from non-ignored transactions by pruning part of the information of ignored transactions.
Assuming that the user clicks on the delete transaction control in (b) of fig. 7, the electronic device displays that item of transaction shown in (f) of fig. 7 may be deleted in response to the user clicking on the ignore alert control. In the example shown in fig. 7 (f), both the card of the transaction and the time node on the time axis are deleted.
Fig. 7 (a), (b), and (f) show examples of interactive procedures for deleting schedule-type transactions.
It should be understood that (a) - (f) in fig. 7 are only a part of the interfaces are cut out for ease of understanding, and in practice, each corresponds to a complete display interface. That is, only (a) - (f) in fig. 7 do not show the complete display interface, and other transactions exist on the time axis that is not shown. Fig. 8 is similar to fig. 7. Fig. 7 mainly exemplifies management of schedules, and fig. 8 exemplifies management of backlog.
Fig. 8 is a schematic diagram of an execution process of a management to-do item according to an embodiment of the present application. In fig. 8, management of the "XX bank payoff day" transaction of the all-day transaction in fig. 3 is taken as an example, and management of other backlog type transactions is similar thereto and will not be repeated. As shown in fig. 8 (a), a card of the transaction is slid on the time axis. Taking the left slide as an example, in response to the sliding operation, the electronic device displays the management control shown in (b) in fig. 8, taking the management control as an example including an important transaction flag control, a deferred reminder control, and a delete transaction control. Assuming that the user clicks the important transaction marker control in fig. 8 (b), in response to the clicking operation, the electronic device displays a change in color of the small flag in the control shown in fig. 8 (c) to indicate that the control is selected, and then in the case that the user does not perform other interactive operations, the electronic device displays an important transaction marker in the card of the transaction, here a red small flag, added to the card of the transaction. As can be seen by comparing fig. 8 (a) with fig. 8 (d), the normal transaction has no small flag, and the important transaction includes a small flag with a color.
Fig. 8 (a) - (d) show examples of an interactive process in which the state of a backlog type transaction is set as an important transaction, and important transactions and non-important transactions can be distinguished by marking.
Assuming that the user clicks on the delete transaction control in (b) of fig. 8, the electronic device displays that the item transaction may be deleted as shown in (e) of fig. 8 in response to the user clicking on the delete transaction control. In the example shown in fig. 8 (e), both the card of the transaction and the time node on the time axis are deleted.
Fig. 8 (a), (b), and (e) show examples of the interaction procedure of deleting a backlog type transaction.
FIG. 9 is a schematic diagram of an execution process for deferred alerting of a transaction according to an embodiment of the present application. Fig. 8 is an example of the deferred reminder management of the transaction "a oral registration" started at 12:00 in fig. 3, and the deferred reminder management of other backlog type transactions is similar thereto, and will not be repeated. As shown in fig. 9 (a), a card of the transaction is slid on the time axis. Taking the left slide as an example, in response to the sliding operation, the electronic device displays the management control shown in (b) in fig. 9, taking the management control as an example including an important transaction flag control, a deferred reminder control, and a delete transaction control. Assuming that the user clicks the deferred reminder control in fig. 9 (b), in response to the clicking operation, the electronic device displays a popup window shown in fig. 9 (c) for indicating a target time for the user to select a deferred. Assuming that the user clicks to select a delay to one hour in the interface shown in fig. 9 (c), the electronic device displays the position of the card of the transaction on the time axis updated to the time after the delay shown in fig. 9 (d). As can be seen by comparing fig. 9 (a) with fig. 9 (d), the corresponding position of the transaction on the time axis is changed. It should also be appreciated that assuming the user selects other deferred target times in the popup window shown in fig. 9 (c), the transaction will be updated to the time node of the deferred. Suppose that the user selects one day later, then the transaction is not visible on the time axis of that day of the target date. The user can also manually set the target time to be deferred to by clicking "custom time" in the interface shown in fig. 9 (c).
FIG. 9 illustrates an example of an interactive process for deferring a backlog type transaction, where the transaction is located on a timeline may be updated by selecting a target time after the deferral.
As can be seen from fig. 7-9, different management controls can be set for the characteristics of two different types of transactions, schedule and to-do, respectively. Because the schedule is more time dependent, no deferred reminder control is set for the schedule, but rather a ignore reminder control is set. For example, assuming that a certain schedule is a high-speed rail trip at a certain point in time, the probability that the user has a deferred reminder is low. Because even if the user clicks the delay reminding control to carry out delay reminding, due to the specificity of the high-speed rail travel, the delay tends to change the time and place of the high-speed rail travel, and the user can purchase tickets again, and the like, so that a new schedule can be generated based on short message identification after ticket purchase. For another example, assuming that a backlog is to buy an item, a deferred reminder may be more desirable to user management than a reminder is omitted. Because the reminding is ignored, the reminding is not needed, and the delayed reminding can also be used for reminding the user to purchase the article continuously. For another example, assuming a schedule to attend a meeting, the user arrives at the meeting location earlier than the meeting start time, the user may have a desire to close the reminder for this schedule, and the user may ignore the reminder by performing the interactive process shown in fig. 7 (a), (b), and (e).
In short, for different types of transactions, different management controls can be set, so that the user can manage conveniently.
The foregoing embodiments mainly describe the possible structure of the transaction management interface and the functions and contents of the various parts, and describe the design and management method of the transaction card for the time axis display area in detail, and the following embodiments will describe the design and management method of the card display area in conjunction with the accompanying drawings.
FIG. 10 is a schematic diagram of a reminder card form in accordance with an embodiment of the present application. As shown in fig. 10 (a), the reminder card may include a title area (or title or summary description), a content area, a theme area, and a button area. The theme zone and the button zone are both selectable items, and buttons can also be understood as controls. Text indicates title content, action indicates button (control) name.
As shown in fig. 10 (b), a blank border area may be provided for the title area in order to ensure the integrity of the content display. For enriching the display content, a small circle icon display area is also set, here, the small circle icon display area is exemplified by 16dp (pixels), in practice, any suitable value can be adopted as required, and other shapes besides circles, such as round rectangle, are not limited. It should be understood that the title area, the content area and the button area shown in fig. 10 (b) are left and right with a white 12dp, the small circle icon size of the title area is 16dp, 8dp blank is reserved between the boundary of the small circle icon and the title text, 8dp blank is reserved between the upper and lower adjacent areas, and 12dp blank is reserved at the bottom of the button area, which serve as an example only and have no numerical limitation.
Fig. 11 is a schematic diagram of a departure alert card according to an embodiment of the present application. The card shown in fig. 11 (a) may be designed using the layout design shown in fig. 10. In the departure reminding card shown in fig. 10, the title content is the estimated arrival time of immediate departure at the current moment, "immediate departure, estimated 7:45 arrival", the content is the road traffic condition and the estimated time, "road is smooth and about 30 minutes arrival", the theme is the trip purpose "high-speed rail trip-Shanghai siphon bridge station", "navigation" control is used for one-key navigation, that is, the map application can be started to start navigation by clicking the navigation control.
The appearance of the travel reminding card can be triggered immediately to prompt the user to start immediately, namely, after the user opens the transaction management interface of the target date, the travel reminding card can be displayed. After the schedule corresponding to the travel reminding card starts, the travel reminding card disappears. As described in connection with fig. 2 and 11 (a), it is assumed that the user enters the my day interface for 7:15 a.m., and the interface is displayed as shown in fig. 2, and the travel reminder card shown in fig. 11 (a) is included in the card display area. Assuming that the user enters the "my day" interface at a time of 8:14, that is, the actual time is later than the starting time of the high-speed rail travel transaction of 8:14-9:14, the travel reminder card is no longer displayed, that is, the travel reminder card in fig. 2 is deleted. Taking fig. 5 as an example, a user enters into the my day management interface, and cannot see the travel reminding cards corresponding to the high-speed rail travel transactions of 8:14-9:14 in the card display area.
It should be understood that there may be only one or more travel reminding cards, and each transaction requiring travel corresponds to one travel reminding card. For example, assuming that there are a plurality of schedules to be on a trip on a certain day, a plurality of trip reminding cards can be generated at different places.
As shown in fig. 11 (a), the user can start the map application for navigation by clicking on the navigation control. When the application is started to navigate, in one case, the map application corresponding to the navigation control is started and a first page of the map application is displayed. In another case, it may be that the map application is started to display a navigation page of the map application, and address information is loaded (filled in) in the navigation page, for example, "Shanghai iridescent bridge station" may be filled in a destination column. It should be appreciated that both of the above scenarios may be implemented, and that whichever is specifically employed may be provided on the electronic device as desired. The first or second type may be selected if the map application allows direct cross-application writing of data, and the first type may be selected if the map application does not allow direct cross-application writing of data.
In fig. 11 (a), in one case, the user can enter details of the schedule of the travel reminder card in the month view interface by clicking on the trunk area of the travel reminder card (which can be understood to be any area in the card other than the navigation controls), as shown in fig. 11 (b). In another case, the user may click on the trunk area of the travel reminding card to locate and completely display the card corresponding to the travel reminding card in the time axis display area, as shown in fig. 2, in this case, the user clicks on the travel reminding card shown in the card display area in fig. 2 (that is, the card shown in (a) of fig. 11), and locates and completely displays the card of the schedule of 8:14-9:14 high-speed rail travel in the time axis display area shown in fig. 2.
It should also be understood that in the embodiment of the present application, the schedule often needs to go to a specific location, and the backlog mostly does not need to go to a specific location, so the travel reminding card mainly aims at the travel requirement of the schedule. Backlog may be totally free of travel demands such as bank repayment, car washing, shopping, new sheet viewing, life payment, telephone charge recharging, etc., and is backlog without going to a specific location.
FIG. 12 is a schematic diagram of a conflict alert card in accordance with an embodiment of the present application. The card of fig. 12 may be designed using the layout design of fig. 10. The conflict reminding card shown in fig. 12 has the title of "conflict reminding" and the title of "2-time-period schedule conflict" (namely, there is a time conflict between 2 time-period schedules), and the theme of "please reasonably schedule time" (namely, indicate that the transaction required to be done by the user is checking and modifying schedule time), and the view control is used for "immediately viewing" the card for locating and completely displaying the two schedules with conflict in the time axis display area.
A time conflict may be understood as an overlap between execution time periods of a transaction. There is a conflict between one transaction, e.g., 8:00-9:00, and one transaction, e.g., 8:00-10:00. For another example, there is a conflict between one transaction of 8:00-9:00 and one transaction of 8:30-10:00. Other cases are not listed one by one. It should be appreciated that for an all day transaction, there is no limit to the execution period itself, so the all day transaction does not appear in the conflict reminder card.
The conflict reminding cards can be immediately appeared, and after the user enters the transaction management interface, all conflict reminding cards corresponding to the transactions with conflicts after the current time are displayed. The conflict reminder card may also occur at the time of conflict generation, that is, assuming that the user has generated a conflict between the managed transaction and other transactions at the management interface due to some management of the transaction card. For example, if the user enters the transaction management interface at 11:00, when the user delays a certain transaction started at 13:00 to be reminded to start at 15:00, and if the user is in the execution time period of other transactions at 15:00, a time conflict occurs, and at this time, the conflict reminding card is updated in the card display area. And assuming that the transaction corresponding to the conflict reminding card does not exist in the card display area, the number of the transactions with schedule conflicts in the conflict reminding card can be modified by adding a conflict reminding card or on the original conflict reminding card. The conflict information can be updated in the conflict reminding card assuming that the transaction corresponding to the conflict reminding card in the card display area comprises at least one of the two transactions.
The disappearance of the conflict reminding card may be due to the fact that the conflict is resolved, may be due to the fact that the execution time periods of all the transactions corresponding to the conflict reminding card are finished, or may be due to the fact that the execution time period of only one transaction in all the transactions corresponding to the conflict reminding card is not finished. The following decomposition is explained.
In one example, the conflict alert card may disappear as the conflict is resolved. The following is an example. When the user clicks the "view immediately" control in the conflict alert card shown in fig. 12, the starting location of the schedule showing the existence of the conflict can be located in the timeline presentation area. Assuming, in conjunction with fig. 2 and 12, that the card presentation area of fig. 2 contains the conflict alert card of fig. 12, when the user clicks the "view immediately" control in the conflict alert card of fig. 12 in the card presentation area of fig. 2, the card with the earliest start time indicated by the conflict alert card can be located and displayed in its entirety in the timeline presentation area of fig. 2, and in conjunction with fig. 2, a "hotel check-in transaction of 12:00-13:00" is located and displayed in its entirety, it can be seen from fig. 2 that there is a conflict between a hotel check-in transaction of 12:00-13:00 and an a oral registration transaction of 12:00. Assuming that the user wants to resolve the conflict, the method shown in fig. 7-9 can be referred to by managing one or both of the transactions to resolve the conflict. For example, referring to the method shown in fig. 7, the schedule of "check-in of a hotel of 12:00-13:00" is left-slid, and then the conflict can be relieved by clicking the "ignore reminder control" or the "important transaction marker control" or the "delete transaction control". For another example, referring to the method shown in fig. 8, the backlog of "12:00 a oral registration" can be resolved by clicking the "important transaction flag control" or "delete transaction control" after left-hand sliding. For another example, referring to the method shown in fig. 9, the backlog of "12:00 a oral registration" is left-slid and then the "delay reminding control" is clicked and the appropriate target time after delay is selected, so that the conflict can be resolved. For example, two transactions may be managed identically or differently, respectively, to resolve conflicts, such as all deletions, one deleting one marking as important, one ignoring one marking as important, etc., which are not listed.
It will be appreciated that when one of the two conflicting transactions marks importance and the other is not marked, the conflict is resolved, corresponding to a priority transaction, and the remaining time is spent to process the non-marked transactions, and the non-marked transactions need not be deleted. That is, the conflict is not necessarily eliminated, and any combination of reasonable management methods may be used to eliminate the conflict. After all the conflicts among the corresponding transactions of the conflict reminding card are resolved, the conflict reminding card in the card display area disappears. However, it should be noted that a new conflict reminding card may be generated after the conflict is resolved, this situation mainly occurs in a delay reminding of the to-be-done item, a new conflict may be generated after the delay, at this time, the new conflict reminding card may occur in the card display area, and the user may continue to manage the transaction based on the prompt of the new conflict reminding card.
In another example, the conflict alert card may disappear when the execution time period of all transactions corresponding to the conflict alert card has ended. For example, assuming that there are conflicts in the execution time periods of 3 transactions, 8:00-9:00, 8:30-9:30, and 9:00-10:00, respectively, in this example, after the time reaches 10:00, the conflict alert cards corresponding to the three transactions may be deleted in the card presentation area. From the user perspective, namely assuming that the time for the user to enter the transaction management interface is 10:00, the conflict reminding cards of the three transactions are not displayed in the card display area.
In another example, the conflict reminding card may disappear when the execution time period of only one transaction in all the transactions corresponding to the conflict reminding card has not ended. For example, assuming that there are conflicts in the execution time periods of 3 transactions, 8:00-9:00, 8:30-9:30, and 9:00-10:00, respectively, in this example, after the time is 9:30, the conflict reminder cards corresponding to the three transactions may be deleted in the card presentation area. From the user perspective, namely, assuming that the time for the user to enter the transaction management interface is 9:30, the conflict reminding cards of the three transactions are not displayed in the card display area. In this example, it can be appreciated that only one transaction is still within the execution period at the current time, and that other transactions, although in conflict with it, have ended the execution period, and that there are no transactions to be processed at the same time, both in terms of the current time and thereafter.
It should also be appreciated that the conflict reminder card may have only one, centralizing statistics and presenting all transactions for which a conflict exists, and only disappearing after all conflicts are resolved (or disappearing after all periods of conflicting transactions have ended). The number of conflict reminding cards can be multiple, which is equivalent to grouping and displaying conflict matters. For example, there may be 3 conflict reminder cards indicating that there are 3 conflict transactions between 8:00-10:00, two conflict transactions between 12:00-13:00, and 5 conflict transactions between 20:00-23:00, respectively. It should be understood that this example is for ease of understanding the scheme and that no numerical limitation exists.
Fig. 13 is a schematic diagram of an open day schedule reminder card and a time anomaly reminder card according to an embodiment of the present application. Fig. 13 (a) shows a tomorrow schedule reminder card, and fig. 13 (b) shows a time abnormality reminder card. The card of fig. 13 may be designed using the layout design of fig. 10. In the statistics data "12 schedules, 2 backlog" of transactions with the topic content of tomorrow, the content of which is the details of the first schedule "in the tomorrow schedule reminder card shown in fig. 13 (a), the content of which is schedule content" cooperatively communicates with a certain company ", the time period" 7:30-12:00 "and the application source" office application C ". In the statistics data "12 schedules in open day, 2 backlog" of transactions with the topic content of open day in the time anomaly reminding card shown in fig. 13 (b), the content is a prompt of "first schedule 7:30, please arrange in advance", which is used for reminding the user of the time of the earliest schedule, the topic is that the topic of the first schedule "cooperates with a company" to communicate with a certain company ", and a strong reminding" control is set to set the earliest schedule as a common open day schedule reminding card, that is, the open day schedule reminding card shown in fig. 13 (a).
The time abnormity reminding card is mainly used for reminding schedules earlier than a preset time point so as to facilitate the users to schedule in advance. The preset time point can be 8 in the morning, 9 in the morning, working hours of working days or the like, so the time abnormality reminding card can be also called an early date and time schedule reminding card.
The open day schedule reminding card is mainly used for displaying statistical data of transactions on the next day of the target date, and if a user wants to preview all transactions on the open day in advance, the user can enter a transaction management interface on the next day of the target date, namely 'my day' of the next day by clicking the open day schedule reminding card.
In the sorting, the tomorrow schedule reminding card and the time abnormity reminding card do not need to be processed immediately relative to the target date, so the sorting can be performed later, for example, the sorting can be performed after the travel reminding card and the conflict reminding card.
The open day schedule reminding card and the time abnormity reminding card are mainly used for previewing the approximate condition of the next day, so that a plurality of cards do not need to be arranged, and the waste of display resources in a card display area is caused. Only one may be provided, respectively.
The time abnormity reminding card can be converted into a common open day schedule reminding card after strong reminding is set. The tomorrow schedule reminder card may then disappear after the zero crossing, i.e. after the tomorrow arrives. The method is equivalent to deleting the daily schedule reminder and generating a new daily schedule reminder after the daily schedule becomes the current day, and can be understood as replacing the daily schedule reminder card which has become the present day with the next daily schedule reminder card. By way of example, assuming a target date of 1 month 3 days, the day of "my day" is 1 month 3 days, and the tomorrow reminder card in that target date displays statistics for all transactions on 1 month 4 days. When the time comes to 1 month and 4 days, the target date is 1 month and 4 days, the day in my day is 1 month and 4 days, and the open day reminding card in the target date displays the statistical data of all matters in 1 month and 5 days.
FIG. 14 is a schematic view of a base card according to an embodiment of the application. The card of fig. 14 may be designed using the layout design of fig. 10. In fig. 14 (a), the title content in the basic card is city and weather information, the content is words of words encouraging the user, and the subject is date information of the target date. In the basic card shown in fig. 14 (b), the title content is city and weather information, the content is words of words encouraging the user, and the subject is date information of a target date and a count-down time of days from a special day.
The date information in fig. 13 comes from the calendar application, and the weather information comes from the weather application. Different words may be displayed during different time periods throughout the day, respectively, e.g., the different time periods may include morning, noon, and evening.
The base card is a resident card of the card display area. It will be appreciated that the card display area will always display a base card. The base card does not appear or disappear with the user's operation, and the user enters "my day" at any time and sees at least one card in the card display area, which includes one base card.
As described above, other types of cards have respective occurrence and disappearance opportunities. For example, the travel reminding card is generated only when a transaction with a travel reminding demand exists, and when the travel reminding demand disappears (when the transaction corresponding to the travel reminding card is deleted or reminded by neglect or the execution time period of the transaction corresponding to the travel reminding card has started, the travel reminding demand disappears), the travel reminding card disappears. For another example, the conflict reminding card may be displayed immediately when there is a conflict, and disappear when the conflict is resolved or the corresponding time period of the card is over. For example, the day schedule reminding card may exist all day by day, disappear when the day comes (the day becomes the day at zero point), and then a new day schedule reminding card is generated. For another example, a special day reminder card hereinafter may appear within a preset date before the arrival of the special day, may disappear when the special day arrives, or may disappear under the user's manual operation of deleting the card.
In one example, the base card cannot perform any operations, and the mailing is preset in the electronic device and cannot be manually altered.
In another example, when the base card is clicked, a weather application may be launched on the electronic device for the user to view detailed weather information.
FIG. 15 is a schematic diagram of a special day reminder card in accordance with an embodiment of the present application. Fig. 15 (a) and (b) show important day reminding cards, and fig. 15 (c) shows daily reminding cards. The card of fig. 15 may be designed using the layout design of fig. 10. In fig. 15 (a), the important day reminding card is shown with the category "important day" in which the content of the title is a special day, and the content is "end-of-period examination", that is, what important day is the important day, and the subject is the date of the important day "9 months 10 days lunar calendar eighty-fifteen". In the important day reminding card shown in fig. 14 (b), the category "important day" with the content of the special day is "F city coffee festival", the subject is the date of the important day "9 months 10 days lunar calendar eighty-fifteen" and 3 days from the current countdown day ". In fig. 14 (b), the birthday reminding card has a title of "birthday" of a specific day, a title of "autumn birthday", a title of "9 months, 10 days, lunar calendar, eighty-five" of the birthday, and a title of "3 days from the current countdown day".
The special day may include at least one of a birthday, a holiday, an important day, and a anniversary. Birthdays may be captured by keywords and synchronized to this point when the user creates a birthday reminder transaction (either a schedule or to-do) in the calendar application. Holidays may also be synchronized by the calendar application. It will also be appreciated that some holidays do not necessarily need to be prepared in advance, and that other ways of reminding, such as a general calendar page, or a date display card on the desktop of the electronic device, etc., may be provided, so that in some cases, a holiday may not be included in a particular day. The important day can be identified by intelligent identification, for example, a series of grabbing of key words can be set, and especially, the important day reminding can be set by the transaction needing to be arranged and planned in advance. Such as the end-of-term exam and coffee bureau herein. The anniversary may then be captured by keywords, which may be synchronized to the calendar application when the user creates a anniversary reminder.
FIG. 16 is a schematic diagram of an interactive process for switching a target date according to an embodiment of the present application. Assuming that the user presses and slides up the interface shown in fig. 16 (a), in response to the slide-up operation, the electronic device displays a reminder pop-up window shown in fig. 16 (b), in which the user is instructed to switch the date by sliding up, for example, the reminder #1 "slide up to view the transaction of the next day" here, and after the user completes the slide-up operation, that is, after the user finishes sliding up by lifting his/her hand, the electronic device displays the interface shown in fig. 16 (c) in response to the slide-up operation. I.e. changing the corresponding date of "my day" from the current day to the next day. In order to distinguish the difference between the "my day" content shown in fig. 16 (a) and 16 (c), different fill colors are used for illustration, but it should be understood that the fill colors are not necessarily present in practice. The interface shown in fig. 16 (a) includes a card display area 1 and a time axis display area 1, and the card display area includes a card 1 and a card 2. The interface shown in fig. 16 (c) includes a card display area 2 and a time axis display area 2, and the card display area includes a card 3.
FIG. 17 is a schematic diagram of another interaction process for switching a target date according to an embodiment of the present application. Assuming that the user holds down and slides down the interface shown in fig. 17 (a), in response to the sliding down operation, the electronic device displays a reminder pop-up window shown in fig. 17 (b) in which the user is instructed to switch the date by sliding down, for example, the reminder #2 "slide down to view the transaction of the previous day" here, and after the user completes the sliding down operation, that is, after the user finishes sliding down by lifting his/her hand, the electronic device displays the interface shown in fig. 17 (c) in response to the sliding down operation. I.e. changing the corresponding date of "my day" from the current day to the previous day. In order to distinguish the difference between the content of "my day" shown in fig. 17 (a) and (c) in fig. 17, different fill colors are used for illustration, but it should be understood that the fill colors are not necessarily present in practice. The interface shown in fig. 17 (a) includes a card display area 1 and a time axis display area 1, and the card display area includes a card 1 and a card 2. The interface shown in fig. 17 (c) includes a card display area 3 and a time axis display area 3, and the card display area includes a card 4.
It can be seen that fig. 16 and 17 exemplify switching of the target date by the sliding operation. This interaction is relatively simple but can only be switched day by day.
FIG. 18 is a schematic diagram of another interaction process for switching a target date according to an embodiment of the present application. Assuming that the user clicks the target date management control in the interface shown in fig. 18 (a), here, taking the example that the management control is located in the upper right corner, in response to the clicking operation, the electronic device displays the date selection popup shown in fig. 18 (b), and indicates that the user selects the switching date in the date selection popup. Assuming that the user selects "9 months 3 days" in the interface (b) shown in fig. 18, the electronic apparatus displays the interface shown in (c) in fig. 18 in response to the click operation. I.e. changing the corresponding date of "my day" from that day to 9 months 3 days. In order to distinguish the difference between the "my day" content shown in fig. 18 (a) and fig. 18 (c), different fill colors are used for illustration, but it should be understood that the fill colors are not necessarily present in practice. The interface shown in fig. 18 (a) includes a card display area 1 and a time axis display area 1, and the card display area includes a card 1 and a card 2. The interface shown in fig. 18 (c) includes a card display area 3 and a time axis display area 3, and the card display area includes a card 4.
The manner of switching the target date shown in fig. 18 can allow the user to more flexibly select the date desired to be switched. But if the user wants to see only the previous day or the next day, it is more convenient and quick to operate using the method shown in fig. 16 and 17. That is, the method shown in fig. 16 and 17 is more suitable for the case where the switching date is closer to the target date, and the method shown in fig. 18 is more suitable for the case where the switching date is farther from the target date. It should be appreciated that both switching modes may achieve the goal of switching the target date.
It should also be understood that the above-mentioned switching target date refers to the target date corresponding to the "my day" of switching, and it can be understood that the content in the "my day" interface is replaced with the one-day transaction of the date after switching.
FIG. 19 is a schematic flow chart diagram of a transaction management method of an embodiment of the application. The steps shown in fig. 19 are described below. Fig. 19 may be performed using any of the electronic devices of fig. 1-18 or 20.
S1901, displaying a first interface of the calendar application, the first interface including a first control.
In connection with fig. 1 and 2, in one implementation, the first interface may be a month view interface or "proxy" interface of a calendar application. The first control may be "my day" in the function bar.
S1902, responding to a first operation of a first control by a user, and displaying a second interface of the calendar application.
The second interface comprises a card display area and a time axis display area, wherein the card display area comprises a conflict transaction reminding card, the time axis display area comprises a time axis and a card of a first transaction, and the first transaction corresponds to a first time node on the time axis.
In connection with fig. 1 and 2, the second interface may be a display interface of the my day function shown in fig. 1 (a), 1 (c), or 2. At least one reminder card may be included in the card presentation area, and conflicting transaction reminder cards may be included in the at least one reminder card. The time axis display area can include a time axis and cards of transactions, and the time axis display area mainly connects the transactions in series through the time axis, so each transaction corresponds to a time node on the time axis. The first transaction may be, for example, any transaction on the time axis of fig. 2, for example, a 6:00 alarm clock may be considered as an example of the first transaction, and a 6:00 time node on the time axis is an example of the first time node, and other cases are not listed one by one.
It should be understood that in the embodiment of the present application, the card display area and the time axis display area may be vertically distributed, or may be left and right distributed, and the arrangement of the reminding cards in the card display area may be correspondingly transverse arrangement or longitudinal arrangement. Referring to fig. 1, in fig. 1, (a) shows that the card display area and the time axis display area are vertically distributed, the card display area is located at the top of the time axis display area, and the cards in the card display area are horizontally arranged, in fig. 1, (c) shows that the card display area and the time axis display area are horizontally distributed, the card display area is located at the left side of the time axis display area, and the cards in the card display area are vertically arranged. The switching of the reminder card of the card presentation area shown in fig. 1 (a) may be performed by a lateral sliding operation, and the switching of the reminder card of the card presentation area shown in fig. 1 (c) may be performed by a longitudinal sliding operation. That is, the direction of the sliding operation of the reminding card is switched to correspond to the arrangement direction of the reminding card in the card display area.
In one implementation mode, the method further comprises the steps of displaying the first reminding card in the card display area in the second interface, responding to third operation of the card display area in the second interface by a user, displaying the second reminding card in the card display area of the second interface, and switching the card displayed in the card display area by the third operation. In such an implementation, the reminder card being displayed by the card display area may be switched through a third operation. It should be understood that the first reminder card and the second reminder card herein may be any one of the reminder cards described above.
When the card display area is arranged on the time axis display area in a top mode, and the reminding cards are horizontally arranged (transversely arranged) in the card display area, the third operation can be a transverse sliding operation on the card display area, when the card display area and the time axis display area are distributed left and right, and the reminding cards are longitudinally arranged in the card display area, the third operation can be a longitudinal sliding operation on the card display area.
In one implementation, after displaying the second interface of the calendar application, the method further includes displaying at least one management control in response to a sliding operation of a user on a card of the first transaction, the at least one management control including at least one of an important transaction marking control, a delete transaction control, an ignore alert control and a postpone alert control, wherein the important transaction marking control is used for indicating that the first transaction is marked as an important transaction, the delete transaction control is used for indicating that the card of the first transaction in a time axis presentation area is deleted, the ignore alert control is used for indicating that the first transaction is no longer alerted, the postpone alert control is used for indicating that a new time node corresponding to the first transaction is determined on the time axis, and in response to a clicking operation of the first management control in the at least one management control by the user, the first transaction is managed according to the indication of the first management control. In such an implementation, management of cards of the transaction of the timeline presentation area is mainly given, with management controls being displayed by sliding operations on the cards, and with corresponding management being achieved by operations on controls corresponding to different management targets. Examples of such implementations are given in fig. 7-9.
In one implementation, the time axis display area comprises a first folding control, the first folding control corresponds to a first time period on the time axis, and the method further comprises the steps of responding to clicking operation of the first folding control by a user, displaying a time period identification of the first time period and the number of transactions in the first time period in the time axis display area, and hiding a card corresponding to the first time period in the time axis display area. In this implementation, the folding control is set in the time axis display area to facilitate the user to fold and hide the transaction according to the time period, and correspondingly, the user can also release the folding state through the operation of the folding control, so that the transaction which is already folded and hidden is redisplayed in the interface. Fig. 4 shows an example of this implementation, where the small icons of "all day", "am", "noon" and "evening" in fig. 4 may be used as the first folding control, and the textual descriptions of all day, am, noon and evening may be identified as the time period.
In another implementation, the timeline display area includes a second expansion control corresponding to a second time period on the timeline, and the method further includes displaying cards in the second time period that are hidden in the timeline display area in response to a user clicking on the first expansion control. In this implementation, the user may be facilitated to re-expand the transaction that has been hidden by the fold according to the time period by setting an expansion control in the timeline presentation area, which may be understood as an unfolded state, such that the transaction that has been hidden by the fold is re-displayed in the interface. The "expansion control per period" in fig. 4 may then be taken as an example of the second expansion control described above.
In one implementation, the method further comprises the step of when the first time enters the second interface, including a card of a fifth transaction in the time axis display area, wherein the fifth transaction corresponds to a fifth time node on the time axis, the fifth time node is determined according to the first time, and when the second time enters the second interface, including a card of a sixth transaction in the time axis display area, the sixth transaction corresponds to a sixth time node on the time axis, and the sixth time node is determined according to the second time. In such an implementation, entering the second interface at a different time would see the presentation of different interface content, i.e., the display of the second interface would locate the time node on the timeline and the card displaying the corresponding transaction at that time node based on the point in time of entry. As can be seen in conjunction with fig. 2 and 5, fig. 2 is a display interface entering "my day" at 7:15 (an example of a first time), fig. 5 is a display interface entering "my day" at 20:20 (an example of a second time), after entering at two different times, the cards contained in the timeline presentation area are differentiated, no 20:30 transactions are shown in fig. 2, and 20:30 transactions are shown in fig. 5, assuming that 20:30 transactions are considered sixth transactions, and then 20:30 on the timeline is the sixth time node described above.
In one implementation, the method further includes displaying a first portion of the timeline as a first color and a second portion of the timeline as a second color when the first time enters the second interface, the first portion being a portion of the timeline before the first time and the second portion being a portion of the timeline after the first time, and displaying a third portion of the timeline as the first color and a fourth portion of the timeline as the second interface when the second time enters the second interface, the third portion being a portion of the timeline before the second time and the fourth portion being a portion of the timeline after the second time. In this implementation, entering the second interface at a different time sees a different time axis color distribution, i.e. the color distribution of the time axis in the second interface will locate the time node on the time axis according to the time point of entry, and the color before the time node and the color after the time node will be displayed as two different colors, respectively. As can be seen in conjunction with fig. 2 and 5, fig. 2 is a display interface entering "my day" at 7:15 (an example of a first time), fig. 5 is a display interface entering "my day" at 20:20 (an example of a second time), there is a difference in the time axis color distribution after two different time entries, black (an example of a first color) before 7:00, blue (an example of a second color) after 7:00 in fig. 2, black before 20:30 and blue after 20:30 in fig. 5. Furthermore, it can also be inferred from fig. 3 that the real time of entering the second interface corresponds to a time node of 16:00 on the time axis, so the time axis in fig. 3 appears to be different in color before 16:00 and after 16:00.
In one implementation, the time axis presentation area includes an all-day transaction portion and a time-division transaction portion, where the time axis of the all-day transaction portion and the time axis of the time-division transaction portion are different in form, and the all-day transaction portion is used for displaying a card for executing a transaction whose time period is one whole day, and the time-division transaction portion is used for displaying a transaction whose time period is not one whole day. In this implementation, the transactions (all-day transactions) without explicit execution time periods and the transactions with explicit execution time periods (time-division transactions) are respectively and intensively displayed, and the time axis is also distinguished, so that a user can conveniently and respectively check and manage the two transactions. As can be seen in connection with fig. 3, a dashed line may be used for the time axis of the all-day transaction and a solid line may be used for the time axis of the part-time transaction (i.e., the time axis of the all-day transaction part and the time axis of the part-time transaction part differ in morphology as described above).
In one implementation, the card of the first transaction includes at least one of a header of the first transaction, an execution period of the first transaction, a locale of the first transaction, and an application source tag of the first transaction. In this implementation, the contents of the transaction card are described, it being understood that other cards of transactions in series on the time axis may be identical to the card of the first transaction. Fig. 6 shows an example of the content contained in the card, and the content contained in several cards in fig. 6 is not identical.
In one implementation, the card of the first transaction includes a jump control, and the method further includes displaying a fourth interface of the first application in response to a click operation of the jump control by a user, the first application being an application corresponding to the jump control, the fourth interface being an initial interface of the first application or an interface corresponding to the jump control. In this implementation manner, by setting the jump control in the card of the transaction, the user can conveniently realize one-key switching application, which can be the first page (initial interface) switched to another application (not calendar application) or can be the interface corresponding to the jump control in the other application. As shown in fig. 6 (b), which is a card containing a jump control, as shown in fig. 3, the jump control may be an identification of the relevant application or a jump link. Examples are also given in fig. 3 where the first application may be a map application, office application #1, video application #2, etc. The user can quickly enter the associated application through the jump control.
In one implementation mode, the card display area further comprises at least one of a departure reminding card, a basic card, a daily schedule reminding card, a time abnormity reminding card and a special day reminding card, wherein the departure reminding card is used for carrying out departure reminding on matters needing to go out in the time axis display area, the basic card is used for displaying date information and weather information, the daily schedule reminding card is used for displaying statistical data of matters on the next day, the time abnormity reminding card is used for displaying matters needing to be arranged in advance on the next day, and the special day reminding card is used for displaying the date information and the matter content of the special day. In the implementation mode, other cards which can be displayed in the card display area are described, namely, the card display area can display different types of reminding cards, the display content is enriched, and the management requirements of users are met. Fig. 11-15 present examples of various reminder cards.
S1903, responding to the second operation of the conflict transaction reminding card by the user, and displaying a third interface of the calendar application.
The third interface comprises a card of a second transaction and a card of a third transaction, the card of the second transaction and the card of the third transaction are positioned in the time axis display area, the second transaction corresponds to a second time node on the time axis, the third transaction corresponds to a third time node on the time axis, and the second transaction and the third transaction have time conflict.
With reference to fig. 2, assume that the card display area in fig. 2 displays a conflict transaction reminding card, and when the user performs a second operation on the conflict transaction reminding card, in a displayed third interface, cards of a second transaction and a third transaction, which have conflicts and correspond to the conflict transaction reminding card, are displayed in the time axis display area. Two transactions such as 12:00 in interface fig. 2 can be considered as examples of a second transaction and a third transaction, respectively.
In one implementation, the conflict transaction reminder card includes a view control therein, and the second operation is an operation of clicking the view control. In the implementation manner, the display of the third interface is triggered mainly through clicking operation of the viewing control in the conflict transaction reminding card, namely, positioning display of the transaction corresponding to the conflict transaction reminding card in the time axis display area is performed, and the setting of the viewing control can more obviously indicate how the conflict transaction reminding card is used by a user. The "immediate view" in fig. 12 can be regarded as one example of a view control, and a click operation with respect to the view control can be regarded as one example of a second operation.
Besides the clicking operation of the check control, the clicking operation of the conflict transaction reminding card can trigger the positioning display of the transaction corresponding to the conflict transaction reminding card in the time axis display area. That is, the second operation may also be an operation of clicking on the conflict transaction reminder card. In this case, the conflicting transaction alert card may not include a view control. In connection with fig. 12, assuming that the card shown in fig. 12 does not include a view control, clicking on an arbitrary position of the card may be regarded as a second operation.
In one implementation, the cards of the second transaction are displayed in full in the third interface and/or the cards of the third transaction are displayed in full in the third interface. In this implementation, when the third interface is displayed under the triggering of the second operation, it is ensured that at least one card of the conflict transaction is displayed completely in the third interface. Facilitating user viewing and management of conflicting transactions. In connection with fig. 2 or 5, two transactions of 12:00 can be considered to be the second and third transactions described above, respectively, and then in this implementation, a card of at least one of the two transactions is displayed entirely in the interface. Assuming that there are many more transactions before 12:00 in fig. 2, the two conflicting transactions that result in 12:00 are not displayed in the interface shown in fig. 2, that is, the second interface at this time, in the above implementation, when the user performs the second operation, the card of at least one of the two conflicting transactions of 12:00 is displayed in its entirety in the third interface. It should also be appreciated that for three and more conflicting transactions, in this implementation, the card of at least one transaction is still displayed in its entirety in the third interface.
In one implementation, the method further comprises stopping displaying the conflict transaction reminder card in the card presentation area when a time conflict between the second transaction and the third transaction is resolved, or stopping displaying the conflict transaction reminder card in the card presentation area when an execution period of the second transaction and/or an execution period of the third transaction is ended. In this implementation, the presentation of the conflict alert cards may be stopped after the conflict between the conflicting transactions is resolved, or may be stopped when the conflicting transactions do not need to be pursued again for their conflict due to the natural time of progress. For the case that the conflict transaction reminding card is stopped when the execution time period of only one transaction is not finished, it can be understood that when two conflicting transactions have the execution time period of one transaction finished, only one transaction needs to be processed immediately or is being processed at the present time, and then the problem of conflict between the currently executing transaction and the finished transaction is no longer needed to be traced. For the situation that the conflict transaction reminding card is stopped being displayed when the execution time periods of all the transactions are finished, it can be understood that the execution time periods of two transactions with conflicts are finished, and the problem of conflicts between the two transactions with the finished transaction is not required to be traced again at the current time.
In one implementation, the third interface further comprises a card of a fourth transaction, the card of the fourth transaction is located in the time axis showing area, the fourth transaction corresponds to a fourth time node on the time axis, the fourth transaction collides with the second transaction in time, and/or the fourth transaction collides with the third transaction in time, and the method further comprises the steps of updating conflict information in the conflict transaction reminding card in the card showing area when the time conflict between any two of the second transaction, the third transaction and the fourth transaction is detected to be resolved, or stopping displaying the conflict transaction reminding card in the card showing area when all the time conflicts between the second transaction, the third transaction and the fourth transaction are detected to be resolved, or stopping displaying the conflict transaction reminding card in the card showing area when the time period for executing at most one of the second transaction, the third transaction and the fourth transaction is detected to be not yet ended. In this implementation, mainly for the case that there is a conflict in three transactions, when only a part of the conflicts between the transactions are resolved, the conflict information in the conflict transaction reminding card is updated, and when all the conflicts between the transactions are resolved, the display of the conflict reminding card can be stopped, or when there is a conflict transaction due to the promotion of natural time, the display of the conflict reminding card is stopped when the execution time period of only at most one transaction is not yet ended.
It should be further understood that, in the case where there are conflicts in four or more transactions, the manner of processing the three transactions is similar to that described above, that is, when only a portion of the conflicts between the transactions are resolved, the conflict information in the conflict transaction reminding card is updated, and when all the conflicts between the transactions are resolved, the presentation of the conflict reminding card may be stopped, or when there are conflict transactions due to the advance of natural time, the presentation of the conflict reminding card is stopped when only the execution time period of at most one transaction is not yet completed, which is different from the above only in that the total number of the conflicting transactions is different.
In one implementation, after displaying the second interface of the calendar application, the method further comprises displaying a fifth interface of the calendar application in response to a date switching operation of a user in the second interface, wherein in the fifth interface, the cards of the card display area and the time axis display area correspond to the second date, and the date switching operation is an up-sliding operation, a down-sliding operation or a clicking operation of a date switching control. In this implementation, a method of switching to a transaction management interface of other dates is presented, mainly by a slide-up operation, a slide-down operation, a switch to a previous day or a next day, and a click operation on a date switching control from a main selection date. Fig. 16-18 give examples of how to switch the interaction method for the date corresponding to "my day".
The method shown in fig. 19 mainly uses the card display area to intensively display the transactions which need to be focused and managed by the user, uses the time axis display area to serially connect all the transactions which need to be processed in one day from the time dimension, and uses the linkage operation of the two display areas, thereby facilitating the user to quickly check and manage the transactions. And the time axis display area displays all reminding matters in the whole day in a centralized manner according to a time axis, so that the centralized management of all matters to be processed in the target date on the same day from a time dimension is realized, a user is enabled to know which matters need to be done in the target date on the same day in total, and is also enabled to know what should be done before and after the day, and accordingly the user can plan the own whole day matters better based on the matters. The transactions which have conflicts and need to be focused and managed by the user are intensively displayed in the card display area, namely, the transactions which most probably meet the management requirement of the user are presented in the card display area in the form of reminding cards, so that the user can conveniently and quickly find the transactions which need to be managed. The linkage operation between the two display areas can facilitate the user to quickly view and manage the transactions, for example, the user can position the corresponding transaction on the time axis display area by clicking the conflict transaction reminding card of the card display area, and then manage the corresponding transaction.
The method of the embodiment of the present application is mainly described above with reference to the drawings. It should be understood that, although the steps in the flowcharts related to the embodiments described above are shown in order, these steps are not necessarily performed in the order shown in the figures. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages. The following describes an apparatus according to an embodiment of the present application with reference to the accompanying drawings.
Fig. 20 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application. As shown in fig. 20, the electronic device 900 may include a processor 910, an external memory interface 920, an internal memory 921, a universal serial bus (universal serial bus, USB) interface 930, a charge management module 940, a power management module 941, a battery 942, an antenna 1, an antenna 2, a mobile communication module 950, a wireless communication module 960, an audio module 970, a speaker 970A, a receiver 970B, a microphone 970C, an earphone interface 970D, a sensor module 980, keys 990, a motor 991, an indicator 992, a camera 993, a display 994, and a subscriber identity module (subscriber identification module, SIM) card interface 995, etc.
The sensor module 980 may include, among other things, a pressure sensor 980A, a gyroscope sensor 980B, a barometric sensor 980C, a magnetic sensor 980D, an acceleration sensor 980E, a distance sensor 980F, a proximity sensor 980G, a fingerprint sensor 980H, a temperature sensor 980J, a touch sensor 980K, an ambient sensor 980L, a bone conduction sensor 980M, and the like.
It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 900. In other embodiments of the application, electronic device 900 may include more or less components than illustrated, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
By way of example, the processor 910 shown in FIG. 20 may include one or more processing units, for example, the processor 910 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (IMAGE SIGNAL processor, ISP), a controller, a memory, a video codec, a digital signal processor (DIGITAL SIGNAL processor, DSP), a baseband processor, and/or a neural network processor (neutral-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.
The controller may be a neural hub and a command center of the electronic device 900, among other things. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.
In the embodiment of the present application, the processor 910 is mainly used for starting an application to load a page and responding to an interactive operation input by a user.
A memory may also be provided in the processor 910 for storing instructions and data. In some embodiments, the memory in the processor 910 is a cache memory. The memory may hold instructions or data that the processor 910 has just used or recycled. If the processor 910 needs to reuse the instruction or data, it may be called directly from the memory. Repeated accesses are avoided and the latency of the processor 910 is reduced, thereby improving the efficiency of the system.
The electronic device 900 implements display functionality via a GPU, a display 994, and an application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display 994 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 910 may include one or more GPUs that execute program instructions to generate or change display information.
The display 994 is used to display images, videos, and the like. The display 994 includes a display panel. In some embodiments, the electronic device 900 may include 1 or N displays 994, N being a positive integer greater than 1.
In embodiments of the present application, the various interfaces are presented to the user primarily through the display 994, such as the various interfaces of FIGS. 1-14.
The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent recognition of the electronic device 900, for example, image recognition, face recognition, voice recognition, text understanding, etc., may be implemented by the NPU.
In an embodiment of the application, the NPU may be used to identify transactions that may generate cards and instruct the processor 910 to generate cards, e.g., may instruct the processor 910 to generate cards in the form shown in FIG. 9.
The pressure sensor 980A is configured to sense a pressure signal and convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 980A may be disposed on the display 994. The pressure sensor 980A is of a wide variety, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, and the like. The capacitive pressure sensor may be a capacitive pressure sensor comprising at least two parallel plates with conductive material. When a force is applied to the pressure sensor 980A, the capacitance between the electrodes changes. The electronic device 900 determines the strength of the pressure from the change in capacitance. When a touch operation is applied to the display 994, the electronic device 900 detects the intensity of the touch operation from the pressure sensor 980A. The electronic device 900 may also calculate the location of the touch based on the detection signal of the pressure sensor 980A. In some embodiments, touch operations that act on the same touch location, but at different touch operation strengths, may correspond to different operation instructions. For example, when a touch operation with a touch operation intensity smaller than a first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. And executing an instruction for newly creating the short message when the touch operation with the touch operation intensity being greater than or equal to the first pressure threshold acts on the short message application icon.
In the embodiment of the present application, the pressure sensor 980A is mainly used for collecting interactive operations of a user, such as sliding operations, clicking operations, and the like.
It should be noted that, because the content of information interaction and execution process between the above devices/units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units and modules are only for distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
The embodiment of the application also provides electronic equipment, which comprises at least one processor, a memory and a computer program stored in the memory and capable of running on the at least one processor, wherein the steps of any method can be realized when the processor executes the computer program.
Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.
Embodiments of the present application provide a computer program product comprising a computer program for performing the steps of the method embodiments described above when the computer program is executed by a processor.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium can include at least any entity or device capable of carrying computer program code to a camera device/electronic apparatus, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (random access memory, RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/device and method may be implemented in other manners. For example, the apparatus/device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
As used in the present description and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".
Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
The foregoing embodiments are merely illustrative of the technical solutions of the present application, and not restrictive, and although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that modifications may still be made to the technical solutions described in the foregoing embodiments or equivalent substitutions of some technical features thereof, and that such modifications or substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.