In the charts, it might be interesting to browse them by time scales in the spirit of this mockup
Left and right buttons to navigate through the data.
This could also solve access to data covering more than one year as mentioned here :
Left and right buttons to navigate through the data.
This could also solve access to data covering more than one year as mentioned here :
I really like this idea. Itâs the most « logical » in my situation where I use charts to track my electricity consumption. It would make it easy to go from one day to the previous/next (especially on mobile).
I donât have any more votes but I support it!
2 Likes
Nice! Totally 
However, the design needs to be reworked ^^
I like what HelloWatt does :
However we donât have exactly the same use case so it needs to be adapted, but it could work like that
Quick
5 Likes
@pierre-gilles I have a bit of time starting tomorrow, and Iâd like to explore this feature request to refine the requirement. I have two questions before I dive in:
- What exactly is missing in the « quick mockup » you proposed on February 17? I have some ideas, but Iâd also like you to tell me, from your developer perspective, what you need to better understand with an improved mockupâŠ
- This concerns making changes around the charts, but I donât fully grasp what the component that draws the charts (Iâve forgotten its name) is capable of. In particular, does everything I propose in the mockup need to be located outside the chartâs drawing area, or can it be placed inside the chart (for example, an arrow to the right and one to the left of the min and max numbers on the x-axis)?
Great 
We need to think about all the interactions Example: There on my quick mockup, we show « last 24 hours ». And if I want to switch to « last month », how do I do that?
In fact there should be no doubt, the only difference between the mockup and the final development is that the final development is in Gladys
You should explore ApexChartsâ documentation and only make feasible suggestions
1 Like
Hello!
So Iâve thought about this feature request. Iâm making a graphical proposal below to show how the new elements allowing navigation through time will be placed. And I will add, especially in a second message, a list of rules to implement so that navigation is as âč logical âș as possible.
New additions:
- addition of a row with two left and right navigation arrows, and in the center the label of the active period (this is @pierre-gillesâs proposal aboveâŠ)
- addition of an element to return to « now »
- addition of an element to switch from âč regular âș to âč sliding âș (Iâll explain just belowâŠ)
- in the period choice list, âč 30 days âș becomes âč 1 month âș
- in the period choice list, remove the words « last/⊠»
The checkbox is a proposal, because I believe that navigation, for example in the âč 7 days âș period, should offer two possible behaviors:
- if, for example, itâs Thursday 3/4 at 6:25 PM, I may want to navigate over 7-day periods all ending on a Thursday at 6:25 PM. This is what I call âč sliding âș mode.
- or one might prefer to navigate over 7-day periods that always go from Monday 0:00 to Sunday 24:00. This is what I call âč regular âș mode.
=> And I therefore propose adding the ability to switch from one mode to the other.
Note 1: All elements are placed above the chart, so I think itâs independent of what ApexCharts can or cannot doâŠ
Note 2: For returning to now and for the âč regular/sliding âș toggle, I didnât make a visual choice: button, clickable text, icon, checkbox, dropdown,⊠I think the developer will make the right choice depending on available spaceâŠ
Visually, it could look like this:
1 Like
The rules (in bold below) are fairly few, I think, so the code to implement shouldnât be overly complex. But I give quite a few details and examples so that everyone can get an idea and spot behaviors that would not be appropriate. Iâm open to your feedback to refine!
====== Navigation with the arrows : ======
- When you click the left arrow, the displayed period is shifted one period into the past (the new end date is the old start date)
- When you click the right arrow, the displayed period is shifted one period into the future (the new start date is the old end date)
Note: Two successive actions left arrow then right arrow (or the reverse) are âč symmetric âș; this returns the x-axis exactly to the same period
Special case: If the end date is >= now, the right navigation arrow becomes inactive (to avoid exploring the future which has no data yet)
====== Change of mode âregular/slidingâ : ======
In regular mode, periods are defined as follows:
- 1h: the period is a whole hour, for example from 8:00 to 9:00
- 12h: the period is a whole half-day, so from 0:00 to 12:00 or from 12:00 to 24:00
- 24h: the period is a whole day, from 0:00 to 24:00
- 7 days: the period is a whole week, from Monday 0:00 to Sunday 24:00
- 1 month: the period is a whole month, for example from 1/1 0:00 to 31/1 24:00, or from 1/2 0:00 to 28/2 24:00.
- 3 months: the period is a whole calendar quarter, for example from 1/4 0:00 to 30/6 24:00
- 1 year: the period is a whole year, from 1/1 0:00 to 31/12 24:00
When switching to âč regular âș mode: the new period includes the previous end date (so we shift a bit into the future)
- Ex1 for a âč 1 day âș period: the display « 2/4 18:25 to 3/4 18:25 » becomes « 3/4 0:00 to 3/4 24:00 »
- Ex2 for a âč 7 days âș period: the display « 27/3 18:25 to 3/4 18:25 » becomes « 31/3 0:00 to 6/4 24:00 » (= from Monday to Sunday including 3/4)
When switching to âč sliding âș mode: the new period « aligns » with the current day and hour (so we shift a bit into the past)
Note: the new end date will be the most recent possible, without exceeding the previous end date
note: aligning on the current day and hour allows falling back on âč now âș when navigating with the right arrowâŠ
The alignment of the period end is done as follows, according to the type of period (taking as an example that the current date is Thursday April 3 18:25):
- 1h: the end of the period will be aligned on x:25
- 12h: the end of the period will be aligned on 18:25
- 24h: the end of the period will be aligned on 18:25
- 7 days: the end of the period will be aligned on Thursday 18:25
- 1 month: the end of the period will be aligned on 3/x 18:25
- 3 months: the end of the period will be aligned on 3/x 18:25, but with x shifted by a multiple of 3 from the current month (so January, April, July or Sept. in my example)
- 1 year: the end of the period will be aligned on 3/4 18:25
Examples:
- Ex1 for a âč 1 day âș period: the display « 3/4 0:00 to 3/4 24:00 » becomes « 2/4 18:25 to 3/4 18:25 »
- Ex2 for a âč 7 days âș period: the display « 31/3 0:00 to 6/4 24:00 » becomes « 27/3 18:25 to 3/4 18:25 » (to end on a Thursday)
- Ex3 for a âč 1 month âș period: the display « 1/4 0:00 to 30/4 24:00 » becomes « 3/3 18:25 to 3/4 18:25 » (to end on the 3rd of the month)
====== Change of period type : ======
When changing the period to enlarge it:
- in âč sliding âș mode, the end date is not modified
- in âč regular âș mode, the new period includes the previous end date
Note: generally the new larger period completely includes the previous period, except sometimes when starting from a âč 7 days âș period
- Ex1: if a âč 1 day âș period is displayed that is a Wednesday, the âč 7 days âș period will go from Monday to Sunday including that Wednesday
- Ex2: if a âč 7 days âș period is displayed that goes from Monday 17/2 to Sunday 23/2, switching to âč 1 month âș will go from 1/2 to 28/2 (thus including Sunday 23/2)
- Ex3 (less intuitive): if a âč 7 days âș period is displayed that goes from Monday 24/2 to Sunday 2/3, switching to âč 1 month âș will go from 1/3 to 31/3 (thus including Sunday 2/3)
When changing the period to reduce it:
- in âč sliding âș mode, the end date is not modified
- in âč regular âș mode, the new period includes the previous end date.
Special case: if this change places the new period entirely in the future, then the new period will actually be the one that includes âč now âș.
Note: generally the new smaller period is completely included in the previous period, except sometimes when going to a âč 7 days âș period
- Ex1: if a âč 7 days âș period is displayed that goes from Monday to Sunday, entirely in the past, then switching to âč 1 day âș will display Sunday.
- Ex2: if a âč 7 days âș period is displayed that goes from Monday to Sunday, but today is the Wednesday of that week, then switching to âč 1 day âș will display Wednesday
- Ex3: if a âč 1 month âș period is displayed that goes from Saturday 1/2 to Friday 28/2, switching to âč 7 days âș will go from Monday 24/2 to Sunday 2/3 (thus including Friday 28/2)
A small flaw with âč zigzag âș navigation in at least two cases:
- In âč regular âș mode, if you start from a fairly old date and chain changes of period âč 7 days âș - âč 1 month âș, you will progressively shift into the future because months donât always end on a Sunday
For example: 6-12/1 => 1-31/1 => 27/1-2/2 => 1-28/2 => 24/2-2/3 => 1-31/3 ⊠But the case is rare, and you will end up âč hitting âș a month-end Sunday or âč now âș, so it doesnât seem too serious⊠- Same if you alternate âč 7 days âș - âč 1 year âș. But thatâs even rarerâŠ
2 Likes
Hi @StephaneB Thanks for taking a look at this!
There are good ideas in your proposal, but I think the UI/UX still needs a bit of work to be more intuitive.
Some feedback:
- The âReset (RĂ Z)â button seems a bit visually bulky. Maybe we can find a more discreet alternative?
- For the âRegular (rĂ©gulier)â button, the intent isnât very clear. As it stands, without your explanation next to it, we donât understand at all what it does. The interface should be self-explanatory; here, without your paragraphs of text, I donât know what it does. Also consider whether itâs something we even want!
For this kind of interface, which already exists in many apps, I think we can really draw inspiration from whatâs done elsewhere. No need to reinvent the wheel Did you base this on any concrete existing examples?
Thanks for taking this on â my remarks are frank but nothing personal aha!
No worries, that works for me
Iâd like it But thatâs not enough to make it a community need, for sure. Iâd be interested in everyoneâs opinions, particularly those who voted for this topicâŠ
I understand⊠So Iâm not a graphic designer, but I just tried to create icons to make this more intuitive. If there are graphic designers in the community, feel free to suggest something else
To clarify the impact of the regular/sliding toggle, it could be this:
et 
And for the return to âč now âș, it could be an icon like this :
Integrated into a graphic, it would look like this:
What do you think?
As I said in my previous message, I think we should draw inspiration from existing interfaces
Before making new proposals, can you do a short study of other interfaces where this kind of pattern appears?
Example with a tool I use daily, Stripe:
Well yes, but noâŠ
The example of Stripeâs Dashboard doesnât seem relevant to me: it works with a kind of configuration bar that opens various large panels to set the observed period and the period to compare with, and what is configured then applies to all the charts on the page. Thatâs not at all Gladysâ logic, and making \âč clean âș the configuration method of Stripe in each of the charts of a Gladys dashboard doesnât seem relevant to me at all.
And furthermore Stripe doesnât offer a simple way to navigate past/future: there isnât a previous/next arrow to move through time, whereas thatâs the objective of this request in @Tolkyenâs initial mockup and then in yours as wellâŠ
In short, Stripeâs interface doesnât inspire me at all for evolving GladysâŠ
Do you have other ideas of existing interfaces? Because I donât have any ideas on my side, and I donât have time to explore âč at random âș⊠If you give me other leads, Iâll gladly take a look
All the options presented work for me, thank you @StephaneB for all the work
I also just looked at the interface offered in HelloWatt, which you had already mentioned. Itâs clean and intuitive, but much simpler compared to what we want to do in Gladys. With them:
- the display is always in âč regular âș mode: a whole day, a whole month, or a whole year
- Since there is no intermediate period type (12h, 7 days, 3 months), the transitions between period types are more basic. Itâs always the first day of the period that is maintained: 2024 <=> January 2024 <=> January 1, 2024.
- no need to have an easy way to go back to âč today âș, since today is never displayed (at best it fetches the previous dayâs dataâŠ)
So itâs difficult to keep their simple interface while offering the richer functionality of Gladys.
1 Like
Iâm available to look into other existing interfaces that implement this kind of time-based navigation on charts, to try to draw inspiration from them⊠Any ideas?
Hi @StephaneB
I donât necessarily have any visual ideas right now, but couldnât we already implement some of the functions available in ApexCharts?
Iâm not really sure how to answer you, @mutmut â maybe itâs more for @pierre-gilles to react based on what he knows about ApexCharts? Not being a developer, I havenât dug into the ApexCharts docs to know what was already possible.
And itâs a bit deliberate too: I think that to do a good job on software, you should, a priori, separate the thinking about the need (which I tried to do) from that about the implementation (which I leave to the developers). And of course if the described need is not reasonably feasible technically, we should discuss to find the right compromise
So on this topic, Iâm available to explore other interfaces if you have ideas and to draw inspiration from them to revisit the requirement I sketched, or to discuss with the developer(s) if some points I proposed are too complex to implement.
The goal isnât to copy exactly what Stripe, HelloWatt or other products do, but rather to draw inspiration from certain proven UI mechanics that work well.
With Stripe, for example, I really like their interval selector: it combines fixed ranges with sliding intervals:
I find their approach clearer than your proposal.
But I agree that the Stripe selector doesnât make sense for Gladys, itâs just an example.
I can spend time on this spec, but that helps me less 
On my side, Iâm putting all my energy into Matter right now.
Totally agree!
Implementation is a detail. The hardest part is writing the spec.
Thanks @pierre-gilles for these clarifications
Ok, I understand. But does that mean youâre ok if I make a mockup that dares to integrate behaviors quite different from how it currently works? Because for now I was making proposals intended to be functional but without having to change the interface too much (both to limit visual development work, and to avoid introducing too much âč disruption âș in usersâ habits)âŠ
No, that wasnât the idea, Iâm happy to keep working on it. I was just asking for leads to explore, but not only from you Iâll explore a bit myself, but Iâm still open to ideas from everyone for sites showing âč navigable âș charts that could inspire meâŠ
Propose whatever you want
I know itâs a bit constraining, but thatâs precisely the whole point of the specification work 
Iâm not joking when I say itâs the most complex stage!
You need to do research: dig through Google, draw inspiration from everyday products, ask the AI questions if needed, or explore sites that gather UX patterns or inspiring design examples.
1 Like
Well, I have to admit, this is a use case where AI really saves time: I described what I wanted to do, and I asked it for examples of sites and components⊠and it really helped me!
I take away several things:
- being able to switch between « rolling » and « calendar » is a common need, but not the need for a button to trigger that switch. In fact, itâs from the very start of data analysis that you know whether you want to be in one mode or the other. So itâs enough to be able to choose between « last 7 days » and « this week » to place yourself respectively in rolling or calendar mode. And then the previous/next buttons will respect this initial choice
- being able to return to « today » is necessary, but a dedicated button is unnecessary. If youâve gone back in time, itâs enough to choose « last 7 days » or « this week » again to return to today
So itâs enough to place:
- the two previous/next buttons
- the display of the currently shown period, which opens a period selector when clicked
- and provide in this selector:
- predefined periods to offer both rolling periods and calendar periods
- the ability to choose dates AND times
And for smooth and logical navigation, there must be automatic synchronization between the chart and the selector. That is to say:
- itâs obvious when you choose a period in the selector, then close it by confirming: the chart should then reflect this new period
- the other direction is not always true in the examples Iâve seen, but I find it better: when the chart displays a certain period (after navigating with the arrowsâŠ) and you open the selector, it should display the information corresponding to that period
Iâve done quite a few configuration tests with a component that I find nice, and which the AI tells me should be compatible with Gladys: DateRangePicker. But compatibility should of course be confirmed by @pierre-gilles or other developers
With this DateRangePicker component, I chose the following options to create the mockup below:
- opens : center
- drops : down
- showDropDowns : true
- timePicker : true
- timePicker24Hour : true
- timePickerIncrement : 5 (minutes)
- linkedCalendars : false
- alwaysShowCalendars : true
And I predefined the rolling periods that currently exist in Gladys, followed by the equivalent calendar periods
- last 60 minutes / this hour
- last 12 hours / this half-day
- last 24 hours / this day
- last 3 days / (no calendar equivalent)
- last 7 days / this week
- last 30 days / this month
- last 90 days / this quarter
- last 365 days / this year
(If needed, I can provide the configuration code of the DateRangePicker that I used)