Thank you!

Thank you! That is a known issue. It hasn’t been reported earlier, but I was aware of it.

It is a bug on the UITableView side — it does that when i chNge the height of the Chart #4 chart.

In the production I wouldn’t use UITableView and would replace with UICollectionView or own implementation to avoid this type of issues.

Telegram has its own table view implementation which also won’t have this bug.

But thanks for reporting!

Wow. That is indeed a bug. Thanks for finding that though!

I went ahead and fixed that too. Please see a slow motion video attached. Alternatively, you can see it here: https://t.me/contest_fixes/6.

That's a very good catch, thank you.

I was unsure what would be the right behavior, hence I did not reply straightaway.

I played around with this and achieved the behavior which I feel makes the most sense. Please find the video attached.

What I do is the following – I keep the "tick" between the Y axis labels and I update Y axis so that the first label starts with zero.

I would not count it as a bug related to this contest, since the goal was to develop a software for showing charts (a.k.a. a reusable framework).

However, since I am planning to upload this work to Github after the contest ends, I digged into the issue and found the cause.

For those who are interested, it is caused by the fact that during the day mode I have translucent navigation bar, and during night mode – opaque one.

As a consequence, when you scroll and change a theme, the content inset of UITableView get changed and that causes that jump.

I did not want to fight UITableView now, because I know Telegram uses a custom one. I fixed a bug simply by making navigation bar always opaque. Please see a video attached.

That is a good catch. As other folks mentioned, you are doing a great job testing our solutions.

I did some further testing, it also seems to happen when you try to scroll when finger is on the range selector border.

Please see a video with the fix attached.

Good catch! There was an issue on my side – I was jumping from the "monthly" scale directly to the "quarterly". As a result, it was showing every third-month label and the label on the left ("Apr" from 2018) wouldn't fit within the screen.

I went ahead and fixed that. Please see a video with the new version attached. I feel that now looks way better.

Agree, it does not look great. It is caused by the fact that I display full month name instead of the shortened version. I, somehow, haven't noticed that designs require to shorten month names.

I went ahead and fixed that too.

There seems to be a bug with attaching videos to the replies. So I went ahead and created a Telegram Channel where I post videos of the fixes. Here you go: https://t.me/contest_fixes

Thanks!

Agree. There is definitely a space for improvement.

On a side note, that is not a draw(rect:). It is a custom property animation on CALayer with the overwritten display().

I wouldn't see it as a major UX issue, because in most cases people use device in one hand. However, since the fix is trivial, I went ahead and updated the behavior.

That's indeed an inconsistent behavior and a usability issue. Please find a fix attached. Thank you for reporting these!

Thank you! I really appreciate that ;)

In regards to the issue – I am not sure I fully understand you. If you mean that the selection line doesn't animate along x axis when you start scrolling and simply fades out, then it is the intentional behavior which I aimed for.

Thank you! :) I really appreciate your feedback.

As always, please find a video with the fix attached. I will be improving X axis in the next following days – I want to animate labels when you tap on the range slider instead of hard-replace.

I've also just created a new TF link with the new build: https://testflight.apple.com/join/5gT9TRL8

> Graphs get clipped in the bottom left corner

That is intentional – I personally believe that it is better to clip it this way, rather than showing the line below the view port.

Alternatively, I could count those points as visible and adjust Y axis. But I also did not like that approach, since those points are technically outside of the view port too.

It is a subjective.

> Values like 884.2k could be rounded a little nicer

I have implemented proper rounding back in stage 1, and I kept it during the first few days of stage 2. After playing with the new charts I did not like the behavior and the feeling. If I round everything nicely to 890K or 900K instead of 884.2K, then Y axis values change a lot.

> Hard to read numbers that are right above the colored graph

I do agree. Back during stage 1 I've implemented labels with the stroke, but removed because it was slowing down the performance on older devices.

There are many approaches on how to solve that.

I played with that myself and did not face any issues with moving the left border in the same conditions as you showed in the video.

From what I can see on the video, your finger is landing on the right border and you are trying to move it left.

I allowed people to collapse range slider as much as possible, so that they can focus on as few points as possible.

However, when two borders are close to each other, you have to be more precise in your touch gestures and try to touch the right border.

I haven't said that having battery saver mode is an edge case.

What I see in this video definitely looks like a bug which I will have to fix. I have a few ideas of what could have caused that – most likely it is related to some tricks which I do with Core Animation.

UPDATE:
I've done initial testing. Seems that Fluffy Ram (and many other apps) update chart without animations. As a result, it has some twitches when moving range slider. Please see first video attached. Moreover, this app has another chart related issue – please see the second video.

It is in not a counter-blaming, neither it is a self defense. I am simply sharing my findings – it might be interesting to other engineers here.

I thought about that, and I believe that it makes sense to disable all animation when user is in low power mode, so that we do not do redundant CPU/GPU iterations.

However, I am still aiming to fight Core Animation and fix it without an easy fix which I mentioned above.

You are right – I left it intentionally.

I am not here to argue.

However, I do not see how leaving it there is easier than removing. It is similar amount of work as removing the columns control view – a couple of minutes. I spent significant amount of time playing with the animation to make UITableViewCell expand nicely and transition from one chart height to another. It would be much easier to simply replace slider with the columns control view.

Thanks for reporting that! Very stupid mistake. Happens 🤷‍♂️

Please find a video with the fix attached.

Agree, it is a minor issue. However, I want everything to look great. I went ahead and fixed that. Please find a screenshot attached.

However, now it feels like the issue is a bit inverse – the line is slightly above Y axis. I will have to play more with that. There are two possible issues – I do weird rounding, or, OS fails to draw at the given coordinate and rounds it to pixels.

Later this week I will publish a TF link to the new build with the improvements to my Telegram channel: https://t.me/contest_fixes

There is a thoughtful optimization in place — on a devices with the A8 or newer processors, I update Y axis in real time. For older devices, I update Y axis only when velocity of the scroll drops, meaning you are done with the scroll, or when you release the finger. 

I wouldn't say it's incorrect, since the correct behavior in this case is subjective. I saw that some people chose the approach of having 0 on each label on Y axis. However, my personal opinion is that not updating Y axis looks better from UX perspective.

That is caused by the fact that I persist the theme between session and load the theme when you open the application. By mistake, I made it to update the theme animated instead of by simply changing colors. And that has caused this weird UINavigationBar behavior.

That's not justification thought. I went ahead and fixed that too. Please see a video attached.

The behavior I have in code is the following:
1. If I can show the info view above the selection (centered), then show it above the selection.
2. If I cannot, because it will cover the selection, then I try to show on the left.
3. If it doesn't fit on the left, then I try to show on the right.
4. If it doesn't fit on the right, then I fall back to showing it above (centered).

The video you posted would be harder to reproduce if I wouldn't have made a mistake in the date formatting for the info view – I used full month names instead of the shortened. Having short month names would make info view narrower and it would fit on the left or on the right.

I fixed that as a part of the "info view twitches" issue which was reported above.

There was no requirements in regards to the iOS version. However, making it work for iOS 8 is not a big deal, since I do not use latest APIs.

Could you please attach a video? I tested on iPhone 5, 6 and 6+. It is indeed not as smooth as on newer devices. But Xcode showed higher numbers, averaging at 45/50 FPS on iPhone 5, and 50 on iPhone 6+ and 55 on 6. 

As contestant #213 mentioned, you might have had power saving mode enabled or measured incorrectly. 

Could you please attach a video? I tested on iPhone 5, 6 and 6+. It is indeed not as smooth as on newer devices. But Xcode showed higher numbers, averaging at 45/50 FPS on iPhone 5, and 50 on iPhone 6+ and 55 on 6. 

As contestant #213 mentioned, you might have had power saving mode enabled or measured incorrectly. 

I do not see it being an issue. I did it on purpose and I see it is an UX improvement, IMHO. I did not like the approach of showing “7 Apr”, “6 Dec”, etc. You need X axis to understand the scale. When you look at the 6+ month scale, labels such as “7 Apr” don’t give you more valuable information than “Apr”.

Could you please attach a video next time when you report an issue?

I just downloaded the TF build, which is attached to this submission, and tested — you can change the status of multiple filters/columns at the same.

You cannot tap fast on the same column to enable/disable it until the animation is finished.

It is not a bug. Byt there is indeed a space for a minor improvement. And I improved that already. If you are interested to see that, please follow this link: https://testflight.apple.com/join/5gT9TRL8

Could you please attach a video showcasing that?

Performance on iPhone 5 is indeed not as smooth as it is on iPhone 6. But it was relatively ok — FPS was around 45/50 during fast scroll on any chart.

Could you please be more specific? From the video you attached I cannot see anything but a nice animated change of the theme.

I kept the X axis from the Stage 1 designs. I plan to improve it. I will update this comment with the video of the fix attached.

UPDATE:
Please find a video with the fix attached.

Yes, it is intential and I see value in that. I do not see any value in showing “6 Apr, 6 Jul, 6 Oct”. I prefer “Apr, Jul, Oct”.

It was not a requirement. My X axis adjusts to the current scale of the graph.

I kept the consistency across all charts — 6 axis. It is a single variable change. However, I see no value in that.

Sorry, but I disagree.

The behavior is the following:
- We try to position view above the selection. If selection is close to the edges of the graph (left or right), then we center it, and then adjust position so that it doesn't go outside of the graph view.
- If we cannot position the view above the selection, then we try to move view to the left of the selection
- If view doesn't fit on the left, we try to move it to the right
- If we cannot move to the right, it remains centered (see first bullet point)

Sorry, but I totally disagree.

We did not have screenshots of the zoomed in chart with the expanded range selector. In the context on 1-3 days it makes sense to display only time. However, when you have more days selected, it becomes hard to understand X axis if it has only times. Hence, I decided to go an extra mile and switch between date formatters depending on the range selected.

1. It is not true. Please see a iOS_1.png attached. It is from the designs which were provided. Half of the screenshots had that border and half did not. I presumed, that it is the choice which engineer can make.
2. I just double checked – iOS_1_Night.png screenshot has color (76, 84, 96), and iOS_4_Night.png has color (44, 53, 65), which I ended up using in the code. I picked colors myself from screenshots before the design documentation was provided, then I compared 2-3 colors to confirm that my picked colors are correct, but I was not checking all 10+ colors, I assumed screenshots have correct values.
3. Agree, it could be improved. There were no colors provided, so I just generate 10% darker color.
4. Agree, that could be improved. Please find a video with the fix attached.

1. Could you please attach the screenshot? I, indeed, haven't tested other locales, but I assumed basic formats, such as "dd MMM" will work on all locales. I'd appreciate if you could provide the screenshot, otherwise I will check it myself later today.
2. I am not sure what exactly you mean. I double checked, my value formatting is aligned with the one on the screenshots.
3. I am not sure what exactly you mean. Could you please clarify?

I made mistake in regards to the date format in the info view – I used MMMM instead of MMM, and that caused some issues with the info view moving a lot. However, it was reported earlier and I fixed that.

In regards to UTC – yes, I time zone to GMT on purpose, so that charts look better and are aligned with the screenshots. Without that, in some locales the JSON data would start from 6 AM. I presumed that when they launch it in production, backend will be providing localized timestamp. And even if not, it will still work perfectly.

It is a duplicated issue – it was mentioned above already and I fixed date formatting to MMM instead of MMMM. By changing to MMM it reduced flickering a lot. With MMMM the width of the info view kept changing a lot – May vs December – almost 3x length difference. 

The behavior I have in code is the following (hasn't change since submission):
1. If I can show the info view above the selection (centered), then show it above the selection.
2. If I cannot, because it will cover the selection, then I try to show on the left.
3. If it doesn't fit on the left, then I try to show on the right.
4. If it doesn't fit on the right, then I fall back to showing it above (centered).

Please try the new TF build with the fixed format – https://testflight.apple.com/join/5gT9TRL8.

I'd appreciate if you could go through all past issues and responses before reporting new issues, so that we both don't waste our time. Thank you!

1. Agree, that could be improved. The logic I have is the following – I take the last hour and then go back by 1/2/4 and so on hours. Since the last date in the JSON was 23:55, all other dates were in XX:55 format.
2. I take the last hour data point from the JSON, which had 23:00 and step back by 1/2/4/8 and so on hours depending on the scale. I don't think it's an issue and I believe that it is the right behavior. (P.S. If the last data point in JSON had 00:00 (as it designs), then X axis would be aligned with the designs too.)
3. Agree, I made a mistake and added one or two scale options which are not the 2 in power of N. If I had 1/2/4/8/16/32/64/128, etc, then I'd not have that issue.