Tablet feasibility study: Your Best Practices, pls?

Hi :cherry_blossom:For my Student Projet, I have to evaluate the cost, time, etc. of building my app not only for mobile but also for tablet. For a feasibility study.
Note: It’s just a Student Project that needs to be as accurate as possible. Not a real project with real managers I have to convince. So don’t worry if you give me a broad idea. You’ll not jeopardize anyone in the process :wink: Just tell me what I should take into account. For an Agile Project. Not a Waterfall Project.

CASE : the app already exists as mobile app. How much would it cost to make it compatible to tablets as well?

Apart from the test time that is at least doubled : Mobile + Tablet
Apart from the Glide Pricing, where Tablets are allowed only for Pro Plan.
What should I care about? I assume the Tablet OS is different from mobile?
So I have to consider it as new devices + OS.
Do you experience common issues that risks time or lead to avoid some features?
What kind of questions should I ask?
Thks for any piece of advice.

Glide apps automatically scale based on the screen size, so for it to work on a tablet, it’s just a matter of turning on the feature and opening the existing app on a tablet. I’m not sure what you are asking. It’s just a matter of having the appropriate glide plan that allows for the tablet/desktop mode. Unless you are utilizing glide pages instead of glide apps, there is no additional development. It’s automatic.

2 Likes

Ok, but you have to test anyway to be sure it’s working on any Tablet, no issues as for font sizes for example?
Do the existing CSS work on tablets as well for those of you who have built for both mobiles and tablets?
The feasibility focuses on all aspects that could affect the cost (time spent, skills required, incompatibility of OS, etc.) if anything should not work with tablets.
So for you, the cost of dev is 0
Only the Price Plan of Glide should be considered?
Thks :cherry_blossom::slightly_smiling_face:

Testing is always good, but I think glide went through a lot of work to make sure the apps scale correctly when using supported built in features.

CSS is not supported and should be used at your own risk and should be tested no matter what. It all depends on how well you wrote the CSS. Some CSS classes differ on different devices, unless you are assured that you are using stable class names that are the same on multiple OS/Browsers. Also, if your CSS relies on specific pixel widths and heights, it may not scale well on larger devices. Using percentage instead of pixels may or may not imrove the scalability on other devices. It largely depends on what you are trying to manipulate. There’s a lot to consider when you start to manipulate a platform that wasn’t built and designed to be manipulated in such a way. Our use of CSS is used to forcefully manipulate the standardized and stable design of glide. I use it to some degree, but in a very limited capacity with the expectation that it could break at any time.

If you stay within the guidelines and specifications of how glide was designed and how it’s supposed to be used, I think you should be pretty safe assuming that it will work on a variety of devices, provided those devices fit within Glide’s minimum recommendations. If you start to add unsupported or experimental features, then you run the risk of compatibility issues. Glide was built from the ground up to scale across multiple different devices, browsers, os’s, screen sizes. It’s only when you start to go outside of those standardized features that you should really take the time to understand what you are doing and test accordingly.

For these reasons, I typically avoid giving recommendations for anything outside of Glide’s supported features. I will share experimental things I’ve done or things I personally use, but it’s enough for me to support my own experimentation, because I know who is using my apps, how they are used, how to maintain them, and what I need to do if an unsupported feature stops working.

All of my projects are personal projects or projects I’m deeply passionate about. That gives me the creative freedom to design apps how I want. It’s not a job for me. My expenses are my time, so I can’t advise on any actual real world financial costs. Only that if you stay within Glide’s built in feature set, then testing should be minimal. If you start to experiment with unsupported features, then testing is paramount depending on your intended audience.

4 Likes

Reading how deep your passion is and how much you value it is just priceless.

Thks so much, Jeff.
Glide & U are lucky to have each other, no kidding :heavy_plus_sign::tophat:
So much empowerment here.

2 Likes

2 cents from me, a lot of things that work on mobile previews need some touching to be able to work the same way on tablets.

Tablets have always been tricky, first because of the difference in their screen structure to mobile apps (the left-side list and the right-side details), second because of the size. Sizing can be controlled to an extent using this, but it’s hard.

https://www.w3schools.com/cssref/css3_pr_mediaquery.asp

4 Likes

Aha! So how do you quantify the additional work to inform about the time & cost required until the job is done?

Is it 30 % + / - risk margin to add
or much more?

would that change anything if you were pairing with another Glider should you have a deadline?

How is your contract structured for your pricing to grant yourself this safe “variable”?
Like per hour, per day, based on transparency & trust or you engage to self on a “package deal fixed price all-inclusive”? to be the only one assuming the risks? For tour customer to feel comforted by his/her budget?
Where can I find a pricing btw from “junior” to expert Gliders? Or if you or anyone can give me a fourchette, if it’s equivalent to any node dev or specific to Glide apps?

I used to be low code dev, admin & project manager, so I know how to evaluate some kinds of dev for business proposals, but not for Glide dev.

Any clue welcome.
Thks ThinhDinh

I don’t price the customers, my colleagues do :grinning_face_with_smiling_eyes: Then I am paid based on the hours I work on the app. The process at the agency involves more steps that contribute to the final product, my building part is just one of them so I can’t give you a full picture on how we price it.

2 Likes

:grinning_face_with_smiling_eyes: Lucky you! ThinDinh. Smart move! :wink:Getting all the fun!
And very well deserved, if I may.
So, I assume your agency checks with you that customer’s budget is ok with their “wish list” before you even start. And in case there are extras and updates, additional contract pages are added as needed, like a collection of the project?

Is it how it works should so request your Expertise via the Experts’ Page and the 15-20? minutes initial call? You “weight” the project the customer “somehow” manage to explain :face_with_hand_over_mouth: with approximative words :upside_down_face::smirk:, and you redirect them to your agency with your “diagnosis” with a “go-no go” personal feeling?

Yeah, I think you describe it right there.

Most of the time I redirect clients to speak with my team, I almost never take calls (I don’t put my Calendly link on there as my schedule and timezone does not let me have a call) or take personal projects.

1 Like