Native Apps (Apple, Android, etc.)

Just chipping in my thoughts here. Normally I’m always the first one to request a mobile app. In this one case, however, I would actually lean towards not being so adamant about it.

Here’s my reasoning (and speaking only from my own experience, I don’t have any insider knowledge on Fibery). What Fibery is doing really is in a “goldilocks” zone. It’s doing things that I’ve never seen, and I’ve seen (and used) nearly everything. There’s literally usecases being solved here that I’ve tried to solve for many years, and often I’m able to implement what I need in mere minutes. I’m thrilled to be implementing this slowly in multiple companies. A lot of the UI is very intuitive (formulas, etc.) and there’s a ton of features that are really nicely built out. That being said, IMHO there’s a very large UX debt because of how many (powerful) features have been built. There’s a lot of simple UX wins that need to happen really bad. There’s also many features that, while VERY groundbreaking, are in my view only ~75% delivered. Huge props and admiration to the whole Fibery team to have the vision and chops to pull off the impossible.

But here’s the catch: adding on native mobile from web-only is a huge lift, requiring much more resources, and demands splitting focus. It’s not at all merely an ‘additive’ function, it’s an exponential increase in execution challenges and resources. This would be even more pronounced given the power (and complexity) of Fibery. That’s not to say Fibery isn’t positioned for this already or doesn’t have the resources - I have no info at all on that.

If Fibery goes native mobile right now/soon, it’s very likely that all the other feature requests - that I believe are crucial not only for usability and existing adoption but more importantly for accelerated growth and operating runway - all those other feature requests would most likely take longer. Maybe some folks here using Fibery more for light biz or personal usecases wouldn’t be impacted as much, but fwiw I’d far prefer to see other areas in the platform addressed first.

Just my 23 cents :laughing:

For background, I’m a product leader in various tech projects/companies, some client work, some internal products. And even thought those are all heavy biz usecases, I’m hoping to also use Fibery for personal too, moving completely off of Notion (LOVE the Fibery “feed view” for that!).

2 Likes

I’ve been using Fibery as my primary daily PKM for a couple months now, including basic things that demand mobile like shopping lists. Quite honestly it works surprisingly well in a mobile browser (Chrome). It feels odd to me that there is very little other feedback in this topic from people actually trying to use the browser version, e.g. “The mobile version is OK, but it needs X, Y, Z to really be good, and I think for that it needs a native app”. This is especially so when you look at recent feedback, and unless I’m mistaken, Fibery team did notably improve mobile over the last year or two (certainly it’s miles better than when I first tried it 2-3 yrs ago).

The one major issue I have is that the Android keyboard selection handling menu shows up over the top of the Fibery one, so it’s difficult and sometimes impossible to do some things with selected text, e.g. formatting or Linking. Not sure if the native cut/copy/paste selection menu is something that can be suppressed in the browser, but I think so. That’d be a nice improvement.

Offline is a whole 'nother level, of course, and probably does require an app of some kind (although doesn’t Chrome have some facility for this?). But aside from that I honestly find Fibery mobile to be largely adequate. What are people’s specific issues with it?

Agreed, mobile web is fairly ok. I would prefer to see a few updates there but nothing remotely deal-breaking, i.e. the other day I attempted to view a timeline on mobile but due to the UX on such a small screen ended up inadvertently moving a few timeline items around without knowing it. Maybe have it start in a read-only view initially for some views (some other vendor just implemented this recently - read only on complex+sensitive views, can’t remember who it was).

1 Like