Responsive/mobile version testing feedback

[trevdor]

Comment here with your findings from testing the mobile release candidate.
We can discuss and figure out which are bugs that need issues created, etc.

[trevdor]

The 'close budget' button on the settings tab doesn't work in the mobile versions of Firefox or chrome, but does work on the desktop version of the browsers (making the window skinny to force mobile mode, then refreshing).
from @MuddledJellyfish on Discord

[tjfinlinson]

The close button does work when rotating the screen to landscape since I'm guessing it's not using the responsive version anymore.

This is from @MikeBishop and his testing.

#433 (comment)

[MatissJanis]

[visual]

Missing bottom margin/padding

[trevdor]

Fixed

[MatissJanis]

[visual]

"offline" label should be white

[trevdor]

Fixed.
Didn't go pure white, but tried to express the same "disabled" state from the desktop width in a color that contrasted with the purple header.

[MatissJanis]

[nitpick]

missing "no results found" empty state

[trevdor]

Good call. Added one. Without some extra plumbing, it doesn't know why there are no transactions in the list, so just kept the text generic for now.

(Also moved the search icon inside the input.)

[MatissJanis]

[visual]

"Accounts" is not vertically centered. To padding/margin is too large

[trevdor]

This alignment came from the native app. I can see why it was done—it’s a nice look (on iOS at least) with the big color block above the heading text. Although that’s subjective, of course.

But maybe let's center to match the Budget view and give Settings the same header treatment. (I'm scared to touch Settings while you're fixing up that screen, @j-f1.)
Then all three views on mobile will be consistent. What do you guys think?

[MatissJanis]

[visual]

Spacing between "close budget" and "about" is too small. Also: maybe we should move "close budget" in to a new block? Similar as we have with e2e encryption.

[tjfinlinson]

Agree with @MatissJanis, that would look nice to have the close budget button moved into a block right above the e2e section I think and add a short explanation.

[trevdor]

✅ Problem goes away in #434

[MatissJanis]

[visual]

Missing bottom margin/padding below "advanced settings"

[j-f1]

Fixing in #434

[MatissJanis]

[visual][desktop]

Only in the mobile branch: spacing between the account name and side-bar is too small

[MatissJanis]

related to: #433 (comment)

Please continue discussions there and not under this report. They both have the same root cause

[MatissJanis]

[functional]

"Number format" and "Date format" selections are not saved and are not being used in the UI.

[trevdor]

My fault. Fixed in #434

[MatissJanis]

[visual][desktop]

Only on the responsive branch.

Reports page has too small top padding/margin

[MatissJanis]

Interesting.

Here's the reproduction (on a desktop):

1. open the preview link with a small screen size (mobile screen size)
2. wait for the app to load
3. maximize the window
4. paddings/margins will be wrong

So perhaps some mobile CSS class not getting removed?

[Kidglove57]

More screenshots

[MatissJanis]

Here's the issue: styles are computed on page load and are not re-computed when dimensions change.

https://github.com/actualbudget/actual/blob/trevdor-responsive/packages/loot-design/src/style.js#L149

[j-f1]

Part of the issue here is that isMobile doesn’t tell React that a re-render needs to happen as far as I can tell. Ideally this would be a global context that is updated using a resize listener, so that React is prompted to re-render all affected components when switching screen sizes.

[trevdor]

I should have noted this somewhere. I was aware you'd have to refresh to get updated styles sometimes. Was going for speed when I had a few days free to work on this in July.

I have no research to back this up 🤓, but I'm guessing resizing below 600px won't be common. The app looks awful for a while before you get that narrow.

Personally, I don't want to improve isMobile so much as to get rid of it. This 600px stuff is quick 'n' dirty based on how the app worked when there was a native app alternative (would push you to your App Store under 600px). But recomputing styles in a resize listener might be a nice stopgap.

I'd like the app to flex as your window grows. No single styles object split between "mobile styles" and "desktop styles." Perhaps 2 breakpoints to accommodate differential styling for small screens, mid-sized, and super wide.

James really wanted to avoid this component switching stuff (which was part of the reason we went read-only), and I'd like to put out a proposal soon for what that might look like. Seems super tricky to make some of the more involved components truly responsive. But at the same time, maintaining what is essentially a whole new app for mobile makes maintenance a pain. New features will get added to desktop and not mobile by accident, or vice versa.

[MatissJanis]

[feature request]

Security of mobile-app. I don't want everyone with access to my phone to be able to just open up Actual and view all my financial information.

It would be nice if we could implement a pin-code (or biometrics?) type of authentication when accessing the app. The auth should expire relatively quickly compared to the password we use for actual-server sync. Would also be nice to have this for the desktop version.

Just putting this out there so I don't forget. No expectation for this to be in the first release.

[j-f1]

Maybe have a quicker expiry on the password? If you have auto-fill enabled it shouldn't be super difficult to enter it again

[trevdor]

👍🏻 Security of some sort would be nice. Although frankly, I might not enable it personally. 😄
Applies to the desktop app, too, doesn't it? My Actual on fly.io just stays logged in all the time.

[MatissJanis]

Warning - subjective opinion below.

In the desktop version I don't care to have extra security. An attacker would need to be able to (1) unlock my laptop and (2) know the exact URL for my Actual server in order to access my data.

Whereas on mobile, I'd have the app on my home-screen. So accessing it would be trivial as long as the attacker cracks my phone pin.

On reducing the actual-server password expiry: I don't think we should do that since it won't work if we implement offline support.

[MikeBishop]

This is what I've been waiting on to jump from legacy into self-hosted Actual. (Really, I'd much rather have transaction entry before migrating, but I assume that's a relatively short step from this.) Some of what I see might be related to the jump, but hopefully it's still useful.

First sign-in from the mobile client works fine, except that the download spinner page looks like this at the bottom:

I assume those ought not to overlap; perhaps stack if there's not enough space to accommodate both?

Initial pokings at the mobile view look fine as long as the phone is in portrait orientation. If my phone moves around and the screen rotates, however, I wind up here:

The left side scrolls to let me switch accounts, but the right side doesn't scroll to show budget contents. Transactions are editable if I select an account. I assume (but haven't read discussion) that it's not intended I be able to reach the non-read-only view on mobile?

[MatissJanis]

Note to devs: perhaps we should change the logic in isMobile to check the user agent along with the screen dimensions?

[MikeBishop]

It would be nice, especially for mobile, to include the ability to "install" an Actual PWA, but neither desktop nor mobile are offering that option on this branch. That might be beyond the scope of this PR, but noting it for future mobile work.

[shall0pass]

I'm able to pin a shortcut in Android, but I thought the purpose behind a PWA was to offer an offline experience. I currently need an internet connection in order to use the app otherwise I get a "no internet available" error .

[trevdor]

I'd love to add a service worker after this is merged! We're local-first. You ought to be able to run it on your phone with no internet ever.

[MikeBishop]

It's not just about pinning a shortcut -- if you take a look at PhotoPrism, it offers an install option:

When you install it, it gives you a shortcut that launches the site with no browser chrome, as if it were a native app.

But this functionality requires a Service Worker first, and the ability to work offline.

[trevdor]

IMO, we should definitely support this for our Android folks. Surely someone in the community has experience. Or wants to gain experience...(if such a person is reading this, knock yerself out with a guide like MDN's).

iOS is pretty lousy in terms of PWA support, but we'll make it the best experience it can be.

[MikeBishop]

Actually, it appears that "Add to Home Screen" does still give you the chromeless launch from that icon, so I stand corrected. Install gives you the offline experience and the ability to schedule background data syncs.

[hugoghx]

The experience on a tablet (in my case iPad Air 2020) is still the same as the desktop experience. Even when explicitly requesting a mobile website, it still gives me the desktop page.

The desktop layout isn't really designed for touch devices, so I think the experience on the tablet should be the mobile one as well. Either that, or there should be functionality available for users to decide which type they want to see.

Tried on: Safari, Brave Browser

[trevdor]

🤔 You raise a great point about touch devices. Gotta think about how to approach that. I hope others will, too.

[Kidglove57]

I am happy enough with the experience on my iPad Air (but I do usually use an Apple Magic Keyboard with it). One or two minor glitches but very useable. It is as tablet sized shrink (the iPad Mini is my example) that the experience becomes very poor.

[culpeppers]

Great work!

I am on an iPhone 11 Pro Max running iOS 16.2 and Safari. A few issues I have noticed:

1. when tapping in the circled area, the keyboard pops up but since it’s read only nothing changes
   

2. This is the only scrollable area in landscape.
   

3. When rotating from portrait to landscape, the UI inconsistently changes between the two here.
   
   

[Kidglove57]

I can confirm this on iPhone 13 Pro. Although oddly I had never before tried to flip to landscape view (I guess because I never did on the old hosted mobile app).

However, I would much rather the current iteration of the mobile view went live and any refinements then follow over time.

[trevdor]

Locking this discussion now that we've merged the initial work.
I plan to move all remaining bugs reported here to standalone bug reports to be fixed on their own.
(If I miss one, please help me out.)