Background
This project was created as part of #wdc 8. The challenge was to re-create an app that was powered by a Google Spreadsheet. I approached the problem by first getting as much of the required functionality as I could in place and then looked for some nice designs that I could use to improve the overall aesthetics of the app.
Steps
- The inspiration for the functionality of this app came from Victoria’s tutorial here on Hashnode
- Next I needed some quotes, which I borrowed from this Hubspot blog post
- I put 21 quotes (7 quotes from 3 categories) into this Google Sheet and shared it with the Community.
- I added the “get” and “sort” functionality to my project. I know there are a few ways to do sorting, and my original intention was to do it in Google sheets, but I found a new(?) way of doing this in the blocks and since it worked I stuck with it!
- Next, I set about improving the appearance of the UI. I found this great dribbble shot by Saleh and used it as a guide for my own design.
- To make styling (and restyling) as easy as possible I went back to Thunkable and used variables to set all the colours for the buttons and labels in my app
- I used this colour palette from coolors.co to “theme” my app, but since everything is set in the blocks it makes future changes really easy.
Next Steps
This was really an enjoyable design challenge - ideally I’d like to add in an “upload quote” option so that it matches the functionality of Victoria’s original tutorial, but having seen Saleh’s design on dribbble I also want to add “favourites” and make the quotes searchable.
Remix
As usual, this project is freely available for anyone in the Community to remix. Feel free to change the design and functionality in any way you see fit, but if you use it for a project please let me know as I’d love to see where it ends up being used.
Why not?
As I mentioned above, I could quite happily spend the rest of the week refining this app but the great thing about the #wdc is that you have a specific goal and a clearly defined end point so it’s very motivating.
If you’re looking for a project to complete yourself then I’d highly recommend that you have a go at the next Weekend Design Challenge.
3 Likes
Nice work! A tangential question perhaps but… is there any hope that the initial screen display in Thunkable will not appear before something like a “set background picture” or “set label’s text” block has a chance to run?
Not a great description… I know… but if you watch your gif, the very first thing it shows for a split second is the word “quote”. In other development tools I’ve used, they rendered changes fast enough that the default label text, background picture, etc. doesn’t appear at all. I’m sure it’s still “there” when the screen loads but the human brain can’t perceive it.
In Thunkable, it’s very obvious and unfortunate. I’m guessing if it could have been fixed it would already have been but it doesn’t hurt to ask!
3 Likes
I suspect the problem is that there’s a trip to the database before the first quote appears. I dealt with that by the quote start out saying “loading…”, which at least looks reasonable. You could also hard-code a first quote, I guess?
1 Like
@catsarisky Thanks for the suggestions. This was more of a general question than something related to this project… I just happened to notice the effect in the gif above. I might be hijacking this topic a little but it’s just something that’s bugged me for a while. I haven’t figured out a way to prevent it from happening because it happens with screen changes where I can’t “hard code” the value. In other words, I’m using a variable as the label/picture value and so it’s never going to look right if I manually enter a value. It will still show that value and then the new dynamic value a split-second later.
2 Likes
Yeah, I hear ya. My FLL team’s app has a bunch of dynamic content, and the loading time is annoying. In that case, I’d intended to leave their content in a Google Sheet, but ended up using the built in DB because it was sooo much faster.
I haven’t done much with it yet, but two things I’ve been thinking about:
-pre-fetching the values I’m going to need
-adding an overlay on the new screen that blocks the partially laid out screen from rendering. (I’d rather have a loading screen than the jump and flicker - but then that’s a second flicker, depending on the timing.)
3 Likes
absolutely! Yeah, my feeling is that it’s always been there and I think it’s more noticable in the live app than an installed app? I’ll have to do a little more digging myself but will double check with the team for you anyway!
I think that’s probably the best approach, because at least a users will understand that if it says “loading” then there’s going to be a bit of a wait.
In the past what I’ve done is set the text to be white (or whatever the background colour is) and then when everything is loaded change the colour of the text. This isn’t as good as your suggestion though because users don’t get any feedback as to what’s happening in the background.
3 Likes
