Signal-ios: Increase font size on main screen (Dynamic type and auto-sizing cells, respecting the system accessibility settings)

[binaryanomaly]

I would appreciate if the font-size on the main conversation overview would be a bit bigger. For me it is too small to read contents from normal distance (iphone 7). Whatsapp for example has an imho ideal size and is better readable.

Edit:
The approach should be to use "Dynamic type and auto-sizing cells, respecting the system accessibility settings" as commented below.

[malhal]

Dynamic type and auto-sizing cells would solve this

[michaelkirk]

Just to add to what @malhal said, if anyone wants to work on this, font size should respect the system accessibility settings, rather than building any special in-app font size control.

[sneakyness]

I'm going to give this one a go, seems like a good starting issue for a newcomer

When we say "Main Screen", we're talking about Inbox/Archive, correct?

[Elland]

I'd gladly look into this for the messaging screen as well. 👌

[malhal]

This will help:
http://www.appcoda.com/self-sizing-cells/

If anyone working on the UI could also make the settings modal instead of pushed that would be great.

[sneakyness]

Just to confirm: This app is currently targeting iOS 8?

Dove in without thinking to check and started using the nice iOS 10 dynamic type stuff (WWDC 2016 Session 205: What's New In CocoaTouch shows a bit of this)

If there is a branch that is targeting 10 that I should be working from, do let me know, otherwise I'll just do it the "old fashioned" way, heh

[Elland]

@sneakyness what are you using in DynamicType that is iOS10 only? 🤔

[sneakyness]

adjustsFontForContentSizeCategory and being able to override traitCollectionDidChange instead of having to do the observer dance

[Elland]

@sneakyness I see. In this case I think its best to do the NSNotificationCenter dance for now.

[sneakyness]

Do we also want to increase the size of the ContactPictureView? (the colored circle with the initials in it)

Inbox/Archive at the top is also quite small, I'm assuming that gets the same treatment?

[Elland]

@sneakyness I think that should get bigger but on a much smaller scale, otherwise it will just overflow.

[sneakyness]

SGTM

I've got the very basics (Name/Snippet are dynamic and update as expected when you change your preference) working so far over here. Basically done for the day, off the top of my head this is what remains:

• [x] Dynamic Name & Snippet Labels
• [x] Updates Label Font Sizes on Preference Change
• [X] Dynamic Timestamp Label
• [x] Dynamic Unread Message Count Label/Bubble
• [ ] Dynamic ContentPictureView
• [ ] Dynamic Inbox/Archive Segmented Control
• [x] Self-size InboxTableViewCell

I'm on vacation right now and will only have a few hours each morning to poke at this, I hope that is ok

[malhal]

For dynamic type you can simply set the font to a text style in IB.

[Elland]

@malhal

For dynamic type you can simply set the font to a text style in IB.

What does this refer to, specifically? Currently it looks like Signal just uses the system font, using preferredFontForTextStyle.

[sneakyness]

Am aware. Was changing what is already in place for toggling styles based on read/unread.

[malhal]

@Elland in @sneakyness's commit he wrapped all the text styles in a font category, I was just pointing out to save all that extra code he could simply set the text style on every label in the xibs and storyboards.

[Elland]

@malhal #1470 😄

[sneakyness]

@mahal do you have any strong opinions/suggestions wrt the unread message bubble? Right now we are rendering it with a fixed size/offset in CG.

I would like to replace this with a vector asset, which would eliminate a good chunk of this code.

(Side note: is there an irc channel or slack that devs hang out in? I had a few other unrelated questions and was unsure where to direct them)

[malhal]

Hi @sneakyness thanks for the message and I hope you are enjoying your vacation!

For the unread message bubble I would recommend taking advantage of Quartz, i.e. _unreadLabel.layer.cornerRadius set to half the width, and maskToBounds, and set the background colour and constraints in IB, the cornerRadius will need set manually in layoutSubviews of the cell after auto-layout has resized everything else. I found this example:
http://stackoverflow.com/a/30367160/259521

[sneakyness]

SGTM! Vacation was great, finally home and ready to wrap this up

What would y'all prefer I do when the unread message count is >3 digits? Unless I missed some logic elsewhere, (I just set .text to 5000 in the cell instead of sending myself 5k messages), this is what it currently does:

My initial reaction is to cap and display "99+" or "∞", etc.

If I'm scope creeping too hard here, just say so and I'll leave it, but otherwise I can't help myself :nail_care:

[Elland]

99+ is better than infinity.

[sneakyness]

Another quickie: I noticed that in updateCellForUnreadMessage, we're attempting to set the time label to be blue (and darkGrey for read), which doesn't have any effect, as the timeLabel is using an attributed string and is permanently darkGrey as a result.

I'm not 100% sure, but I think if you're exclusively using the simulator to test, at some points (maybe even currently) it would have been possible to write this code and have the time label appear as blue.

So, do we want the time label to also be blue for new messages? I _could_ do git-archeology and see which came first, but I thought it made more sense to confirm intentions here.

There isn't any sort of design/spec I could be checking, is there?

[michaelkirk]

So, do we want the time label to also be blue for new messages? I could do git-archeology and see which came first, but I thought it made more sense to confirm intentions here.

It does look like that was the original intent, please restore it.

There isn't any sort of design/spec I could be checking, is there?

Like dust in the wind AFAIK.

[binaryanomaly]

Should there be any progress visible by now? Obviously something was done but I still have the same small, barely readable font on the "Inbox" conversation overview?

[sneakyness]

@binaryanomaly, Going to be honest and say that I'm not a big fan of the tone/entitlement you choose to complain at me with here. I would suggest being a little friendlier when demanding status updates of work others have chose to do in their free time. If you even bothered to build and run a copy of my branch (you didn't), you would see the text can be quite massive

Anyways, got kind of sidetracked after vacation with the holidays, family. Not even sure where I left off, I'm pretty sure I was in the process of re-constructing autolayout of the cell to fully accommodate the very largest text sizes and bold text. If there's a "good enough" to be had here do let me know. In it's current state it's certainly more usable than it was previously, and some 'missing' features are restored, but I personally would like it to be more polished.

There's also an issue where the cells aren't properly resizing to their new height until you leave and return to the screen, after changing the text size. I think the quickest compromise would be to only have 1 line text snippets. I'm probably just missing a call somewhere for the heights, a second set of eyes would be very nice.

I had been meaning to wrap this up, and felt guilty when I saw two other updates go out recently, but this person's behavior reminded me why I stopped contributing to open source. I have zero motivation to appease this anonymous armchair project manager, demanding progress updates without even attempting to try the progress that has been made so far.

I might get around to bringing my branch up do date and cleaning up the styling in the next week.

[m-cerveny]

@binaryanomaly I'm sure you know where you went wrong by now.

@sneakyness @Elland Thanks for your efforts and insights. I'd like to reiterate on the usefulness of this feature. Especially, for older people (like myself) who do not see well without glasses. Messages are nicely using dynamic text size, but Inbox/Archive do not. If possible, please look into it. You will make many people happy. Cheers!

Btw, is [help wanted] related to implementation, design, or testing?

[sneakyness]

I think the best place to start would be with a proper iteration on the design of just the message display cell. The current layout was not created with changing text sizes/expanding cells in mind, and this becomes extremely apparent when you use anything larger than "Medium" (~24pt for the Name Label) or so, if you have the accessibility setting toggled to enable the extra-jumbo dynamic text sizes. Otherwise, I think that would be large/larger on the default.

A good example of one of the first issues you will encounter with larger text sizes would be that the Timestamp/Date Label start to interfere with the Name Label. In the screenshot linked in my last comment, the timestamp is already using ~1/6th of the horizontal space of the screen. Names have a habit of being especially long.

Neither label is in a particularly bad spot, but some actual "design thought" needs to go into the contextual needs when using this screen. Using the same screenshot, you can see that my name takes up ~45% of the screen width. If I had entered my full name in (Nicholas), it would be truncated to something like "Nicholas Pan…"

There are a lot compromises that both the name and date label can make, but I am not comfortable with selecting one "correct way" to display names and dates. Personally, I feel that there are multiple completely legitimate justifications for wanting to do things such as hiding the first/last name and timestamp on the main screen entirely. The avatar/colored circle with the initials along with a preview of what was said last is typically more than sufficient in my experience. Having such a long list of exact times and dates of who I have spoken with on display tends to cause me to think twice about when/where I have the main screen of Signal open. The preview of the message is typically much smaller, and light grey, making it sufficiently hard to shoulder surf anything of value from.

I think the ideal solution would be to have 3-5 "Detail" or "Verbosity" levels for the main screen/message cell, and dial that value down, to a lower or less verbose setting, as the dynamic text size increases. Small changes like opting not to display the "/17" of all dates for messages sent this year ("4/20" vs "4/20/17"), and only displaying a First Name/Last Initial (or the opposite, so "N. Pannuto" or "Nick P.") tend to be the difference between having to truncate/wrap labels and a clean user experience. This is especially true for those who employ screen readers and must "listen" to the interface, even if they do so at what most people with eyesight would consider "insanely fast" speeds. So just a slider with 3-5 levels, and individual toggles to show or hide the name/timestamp entirely, are things I would 100% use. The toggles are optional, and the slider does not necessarily have to be exposed to the end user.

While we're on the topic of timestamps and date labels, I would be less likely to immediately disable the display of mine if there was a way to opt for fuzzy dates that emulate the way iMessages does it. Also under "extremely nice to have" would be to hide the timestamps in the messenger view until I slide my finger to purposely reveal them.

I think the most useful thing right now would be evaluate the state of the current design for the message cell on the main screen. Basically: Open up signal at each of the dynamic text sizes and take a screenshot to get an idea of how big things get at each size, and with that knowledge, design 3-5 different message cells to accommodate the hugeness. Ideally they would all still look handsome if either the name or timestamp is omitted.

I specifically chose not to update my fork for compatibility, as I didn't want end users relying on a half-baked implementation for something that cannot really afford to be anything less than "done right". Doing so tends to be sufficient incentive for non-developers/non-powerusers to try and figure out how to clone the fork and build to device themselves, which seems dangerous given the potential use cases of this app. Thankfully/Unfortunately, we are at the point where an up-to-date version is necessary for further progress.

I've set some time aside Monday for updating the Dynamic Text fork so that anyone inclined is equipped to contribute. I've since acquired a Sketch.app license since I last poked at this, if it would be helpful I could recreate what we currently have in that?

Implementation help is always welcome, but based on everything I found in breaking this down to basic details, the only record of the way things are supposed to be is more or less the way things currently are. I feel that any development effort would be better spent elsewhere until we have a definitive design for the message cell layout at each of the dynamic text sizes. I also think that once we have one, others might be more willing to dive in and help. Right now. the end goal is pretty nebulous outside of "good enough". I would like to be aiming closer to "done right"

There is nothing to Test, as we have already confirmed that dynamic text functions in message cells.

[m-cerveny]

@sneakyness That was a very nice and elaborate reply. I very much appreciate it. I feel the complexity better now. I will try and get a cheaper sketching tool (Sketch is just too expensive for this one occasion for me) and will try and reiterate on design possibilities.

I'm afraid, that making a "right" solution is impossible, though. If you increase the text size to humongous and go to Messages.app on you iPhone, you'll see truncated (with ellipsis or otherwise) texts as well. And it is not pretty. However, considering the people who must "listen," I do not think it will be a problem, since (I hope for Apple's sake) the displayed text is just representation of the data in the model and the reading is done using the underlying data.

Bottom line, thank you for breaking it down. I will see at what rate I will be able to contribute (designs / ideas / etc.) and hopefully this will get some momentum. If not anything else, this helped me appreciate the design (not security) decisions of Messages.app more... with a bitter-sweet aftertaste...

[m-cerveny]

This issue can be closed. Dynamic type supported throughout the iOS app since 2.24.0.10!

Thank you all for contribution!

[sneakyness]

@m-cerveny Would you like a copy of sketch? Shoot an email to [email protected], it's honestly far too good to not have if you do UI at all