task[1]
0344034.
BDCM
.Application Design II
::task[1]
task[1]: App Design 1 Self-Evaluation & Reflection
todo:
- Write reflection of App 1 project outcome
- Find usages of Gestalt Theory in App 1 project outcome
reflection:
In Application Design I, I made an app called "nomaid" & there are a few things I think weren't done up to the best in hindsight. Whilst I still am proud & satisfied with the final outcome, the possible improvements given the time & resources beyond the 14 week limitation, is undeniable.
Figure 1.1.1, Live demo of nomaid, 10/7/2022
https://ljslol.notion.site/ljslol/app1-project-4-prototype-fe813e17f763471e8def806bf2ac211f
Layout
Module dropdowns❌
|
✔️
| ||||
FAB groups❌
|
✔️
|
Execution
Lack of contentful screens
Since the idea was to build a platform that would integrate with various on-device & cloud services, most of the mind-space was dedicated towards everything around the concept & interface that would enable such functionality, rather than the functionality itself. Like Mr. Razif said, "building an API". This meant that in the prototype, the screens that would be presented as the main functionality for a user, only were relegated to input boxes & text labels.
A more """visually stimulating""" experience should be put forth, not only to ensure users aren't intimidated, but just increase their overall ease-of-use. Everyone loves a few pictures. In hindsight, more care & thought should've been put into presenting that area better, perhaps leading harder into Google Home or Home Assistant integration with tile based UIs, or more into phone automation with an AutoInput-esque setup flow, perhaps even just making a bigger fuss of the (at presentation-time, broken) IntelliSense-like autocomplete that has icons & too the variables that retain type information.
All-in-all, I still think the concept & the majority of the app was """there""" at presentation-time, it's just the lack of a """sellable""" key feature or """wow""" screen, really hampered its appeal.
Limitations of Adobe XD
Maybe I should've used Figma 🤷. The grass is always greener on the other side, I guess.
Adobe XD gave me tonnes of issues & kept me constantly fighting against it. Here's a self-quote from my """closing-words""" of the project itself, that I think encapsulates how I felt about the whole ordeal:
"Pushing XD to its limits feels a lot like driving very close to the sun. My car (analogy for brain) is not designed for the surface of the sun (analogy for Application Design 1)."
Not only was state management a pain, a lot of visual features, like runtime flexbox-like layouts, was simply absent & definitely dragged my final outcome down a few steps on the goodness-ladder.
There were even some features & ideas that I simply couldn't express inside XD. These meant that they had to be separately implemented, fragmenting the prototype. The main two culprits were the animations & ResResList. The former was simply difficult to show, as there isn't really a 1-to-1 example of animation anywhere. I probably should've done some simulated animations in After Effects or something, but in a time crunch I could only show what I had. This not only generated extraneous questions & turmoil, but also was just kinda unpleasant for the audience of the presentation. ResResList was a different beast on its own. I wanted a responsive list that had previews for what was inside each module. However, if one were to simply arrange cards along a typical list view, the information density would've been even more atrocious compared to information-dense competitors like Tasker. This lead me to implementing ResResList separately to showcase my hard-to-explain-using-static-imagery, difficult-to-animate-traditionally concept which solves that problem.
Whilst I am very proud of ResResList, it's not perfect, needing much optimisations & probably a refactor to remove dependency on JavaScript to perform its layout. It is also just confusing, as its layout differs quite a bit from the one presented in XD, causing the presentation audience to fail to form the linkage between how the movement, animation, & scrolling would work, compared to how the normalcy of all three attributes in the XD prototype.
In conclusion, probably use Figma, & don't reimplement parts of a prototype in multiple places (eg. reserve an empty spot to show ResResList instead of putting a list & pointing to ResResList as its replacement).
Big scope, small time
The scope for the app was objectively, silently massive. It attempted to improve upon & combine the technical-prowess & containerisation of Tasker, the user-friendliness & cloud-connectedness of IFTTT, the UX & user-adoption of Apple's Shortcuts, the store & portal-esque UI of Macrodroid, all whilst reinventing list-data-display.
"14 weeks is never enough."
What I probably should've done, is to have tackled a subset of any one of those apps & excel in that, instead of attempting to pluck a leaf off of every plant to form a garden. That would've enabled me to focus on polish & experience over needing to take into account every single corner of a virtual apeirogon.
Closing words
In conclusion, time, technical, & resource constraints restricted the quality of the final product, but that's not the end of the story either. All three of them could've probably been used more efficiently given further optimisation to the idea, but there comes to catch-22 of a lack of those three aspects on the idea itself (the first few weeks of Application Design I was basically a waste). I guess all that matters now & all that has probably ever mattered, is that I'll be able to produce something much more refined given the same timeframe & topic, now or much further in the future as needed.
Gestalt
The principles of design are very important to a design's viability & clarity. It's this case which compels a review on whether Gestalt principles were properly applied onto my final output of Application Design I.
Figure 1.1.2, Gestalt theory in nomaid, 9/9/2022
Comments