Designing for the future (PWA) - pages or groups?

You can set cookie variables using the toolbox javascript plugin. If you don’t want to dirty your hands with code i think @jarrad has a plugin that can easily help you store data to local storage (see post below). I have my own personal plugin for browser storage but looks like @jarrad’s version does a similar thing and even more (encryption).

1 Like

I believe my issue with the collapse operation is that I have a full height sidebar menu that’s floating relative to both top and bottom, and thus has to be the entire height of the page for it to work properly. As such, I don’t think there’s any way to collapse this to a minimum height or something.

Anyone have any ideas?

Is the Sidebar menu a plugin? Or one you’ve created manually? Do you have items in the menu that need to be stuck to the top and bottom? Or just to one?

Thank you very much for explaining. It will surely come in handy.

@andrewgassen it’s one I’ve created manually, it’s always present on the desktop viewport. It’s supposed to be present always on the left side of the screen, see below

1 Like

You could set the page bg to be white, make the menu items the only things in the floating group, then set the groups themselves to have the gray bg color.

any solutions @jordan.shotwell? Thanks!

Nothing I’ve found that works, unfortunately…

I’ve built a similar side menu. I am not sure i understood what you are trying to achieve, but I am sure we would built some solution to your problem. Do let me know

@jordan.shotwell I have successfully built collapsible structures with floating side menus in the past without problems.

try experimenting with enough spacing both between groups as well as to the sidebar to begin with.

Get it working with large constraints then expand.

When I have had issues, it has often been overlapping layers, over or under eachother. Can be a hell of a job to find out if you have lots of elements.

If your web app will be LARGE (40+ views/groups) and you can sustain load time for separate pages I would recommend that for the time being. Bubble suddenly becomes bothersome to build in when you have too many groups on a page. Also the stacking approach with collapsible groups is NOT fun when you need to expand sizes of groups higher up.

1 Like

That’s huge, What kind of app is that?

If you’re planning to use a system like dropsource, having your app in native form to begin with makes life easier.

Top secret for now :joy::ribbon:

Dropsource has too much limitations IMO for semi complex apps for now. Many people fall into the trap of starting to build and after building into a corner, realizing that something like Dropsource does not cover what they need. Dropsource can be great, just ensure you know it covers your needs.

The hybrid space is indeed interesting, phone processing power is increasing rapidly and for many types of applications that don’t require the most complex UI fanciness it should do fine.

100% agreed.

If you take a long-term/high altitude view of this insane business, more and more people will be encouraged to use some sort of lite app. Standards contract in cycles for consumer applications quickly.
See: Java -->Javascript, Flash–>HTML5

Lite apps are a spectacular fit for Bubble+Dropsource to provide a longer-than-expected run in the Google store. (Web-based content  |  Android Developers). We seemingly won’t have to rely on as many functions/workflows being run twice if we smush Bubble+DS enough, in the right way.

This is not a one-size-fits-all approach, but if your plan is to bring something to market in order to raise capital, having a few rough edges across all platforms isn’t horrible. In my experience, investors like to pay (to an extent) for next-phase production as opposed to necessary upgrades. It gives them a shiny, tangible, result of their investment that they can show to their friends. It shouldn’t be your investor’s primary reason for investing, but I have yet to meet one that doesn’t like it.

To bring this full circle, having a native, group-based Bubble app to use at certain points in your Dropsource app, allows us to compartmentalize, the key to a proper UX.

Yep, valid points. Although it all comes down to actual feel, whereas Im a little skeptic :slight_smile:

How does the dropsource app feel with group based webviews for some of the app parts? Able to share a high-framerate GIF showing the actual flow or feeling?

Any details and or feedback is appreciated.

Are you talking about multiple bubble groups in a webview? If so, I’m doing that now and it’s tricky. I’m trying to put as much UI into device memory before I make the webview call. I’m building more bubble to accommodate than I had expected. The feel is a factor. I’m not sure how much is a matter of the mobile emulator. What bubble delivers to a stand alone browser is an app in itself, so it becomes an app within an app.

How do you manage logged in state btw?

Do I have to log in twice ?

As long as your app is not native you need quite a few native functionalities to get it approved for the app store.

I think it’s a silly mindset to have especially when so many apps nowadays are hybrid.

However I do see a lot of iOS apps now that have native controls but the content sits in a we view wrapper. Maybe that’s the way to go but it is still quite some work.

@vincent56 I’m sure that any bubble app with push notifications would suffice. Apple changed their terms after peer pressure about the bad language. As long as the company who owns the app generates the binaries we should be fine.

The only risk I see is that it does not store the html in the app but fetches from URL.

@emmanuel would it be possible to enable cross origin requests, namely CORS - for a mobile app which is primarily serving from local folder?

This would help us immensely in pushing the mobile / PWA frontier. And right now this is a huge obstacle.