Tuesday, 5 September 2017
I was assigned to critique Airfrov (Group 9).
A. Summary of what the presenting team said about the application that you think is most important. Focus on three points and explain why you feel that they are the most important points.
B. What are your thoughts?
The three points most important to me are: the "bad", suggested improvements, and key learning points (iow, what they learnt from their research on Airfrov).
The presenting team first gave an introduction to what Airfrov does. Airfrov is a web platform for non-travellers to purchase items available exclusively overseas from travellers who are, or are going overseas and can purchase those items in-person.
The team then moved on to "the bad". There were three main "bad" features of Airfrov, according to the team. The main criticism was on the appearance (UI) of the app.
Firstly, there seems to be too much information on the website's home page. The introduction to Airfrov's purpose and benefits for users clutter the page with loads of text. To better illustrate the clutter, I have a screenshot below:
Secondly, the team claims that there is too much white background / space. An example of excess white background / space could be the following screenshot:
Last but not least, the presenting team criticized the choice of colours (pale and unattractive) for the website on the basis that it is essentially an e-commerce / marketplace platform and ought to follow the established e-commerce platforms like Amazon, which use flashy colours.
The presenting team then suggested improvements for the app. There were three improvements mentioned. Firstly, the bullet point was "more abstraction needed from users' POV". It means users should be given a more simplified UI (less text, for example). This improvement targets the first "bad".
Secondly, the presenting team felt that the platform should have social features that encourage customer and traveller interaction. An example of such a feature could be instant chat/messaging on the platform.
Last but not least, the presenting team suggested improving the UI for the "price offer" (not sure of the exact phrase) pages, as they have shown that the pages were uninformative, with only a single button to enter the amount to offer for the potential product in question.
Finally, the presenting team mentioned some key learning points discovered during their research on Airfrov. The only learning point which I recall and can put into words is this: The team observed that there are people who want to earn extra keep, and there are people who are willing to pay high prices for items that are exclusively overseas, and these lead to a large profit margin, part of which Airfrov can benefit from.
Thanks to the presenting team, I managed to learn about such an interesting business idea and how technology plays (yet another) big role in it (:
My thoughts will be broken down into two parts, the UIUX critique and the feature request critique. I will talk about my thoughts about the presenting team's points, and add in my own points and other observations.
Firstly, I cannot agree with the presenting team's critique on the UIUX (the "bad"). First, the landing page was cluttered with the introduction and seemingly irrelevant content (irrelevant to purchasing) because the user was not signed in. This could mean the user is a first-time user (like me), and he/she needs to read on to see if Airfrov is the right platform for him/her. What AirFrov could have done is to make sure the white text stand out more, as the white text is the definition of Airfrov. Screenshot below:
The screenshot looks like it has captured the white text in the picture very well. But in reality, it is a carousel that rotates. The last two carousel image and description refer to more advanced features like "I WANT THIS TOO" and secure payment. I feel that those two carousel images would not have played any part (i) convincing new users to join, (ii) alert current users of such cool features, as users would have scrolled down before the carousel reaches the last two alerts. Users generally scroll up and down.
Furthermore, I felt that having "excess" white background / space is not the problem. The problem would be more of alignment. In the example screenshot above for the Post Request form, the page has already fulfilled its purpose as a form. There are placeholders to guide the user along the form. However, it seems weird that the form is aligned to the left, and directly below the icon on the left. It could be a design choice. But the form looks good on mobile, except...
The portrait screenshot is a screenshot on my Samsung phone, while the landscape screenshot is a screenshot on my laptop (same as the one above, but reproduced here for ease of reference). On my phone, there is no way I am going to know what that pencil icon by itself can do (it collapses the form section). In my opinion, I prefer a collapsible that is more visibly marked (like a solid rectangle, for example, this), so that I know where to click, where to tap.
Last but not least, I felt that choice of colours was not something to criticize. (Screenshot reproduced below for ease of reference)
It does not have to be a flashy colour that stings our eyes. What I felt could improve the seeming "plainness" or "whiteness" could be just changing the border to one with a darker shade or shadow and clearly define a boundary between each product card. Below is a simple experiment to darken the box-shadow. The original opacity was 0.2, and I max-ed it up to 1.
We can see the difference between the product cards and the categories card on the left (which I did not edit). But oh well, this could be just a matter of preference and taste. A light box-shadow will look as if the image literally got slapped on top of a white canvas without clear borders. Someone in the comments section may beg to differ.
Now for the features part. I agree with the presenting team's argument on text clutter, even though I feel that the landing page should still have some sort of introduction for the not signed-in users. But then again, it could be because I am the only lazy person who refuses to read the information (after being spoon-fed with lots of analyses by the presenting team). Personally, I hate the carousel for the not signed-in users. It not only confuses me, but also distracts me (I end up not reading the text properly). A two-column or two-row banner would help emphasize the duality of this app (catering to both "peer buyers" and "peer sellers").
My memory is slowly fading away, and I remember less and less about Airfrov. I shall sign off now. I hope to hear your comments on my critique, and perhaps correct me if my memory has already failed me. Thank you.
9 comments | Leave a comment
Friday, 1 September 2017
I have been under a lot of stress lately. I have two research modules on top of CS3216. In addition to that, I have a couple of non-academic commitments which I am unable to let go yet. In NUS Hackers, I respond to my juniors if they need any advice with organizing hackerschool. In Computing Club, I need to maintain the Computing Club websites, and more recently, the Elections. I am inside the Elections committee, and there were some hiccups in the Elections due to the committee's inexperience.
But that's not all. My team mates in CS3216 are relatively inexperienced. So I took the initiative to maintain the technology stack from server to back-end (excluding database schema). I also maintain the version control and review PRs. I also update my team mates regularly on what I have done and what I am going to do. For the first two weeks, I am the only active contributor. I ping my team mates once every 2 or 3 days.
Progress was slow, and I have no idea why. Someone was sick, that is OK. Someone had meetings, that is not really OK..., because I skip mine for CS3216, but nevermind. Someone remained quiet, and was able to sleep in peace at 10.30 PM (I cannot fall asleep in peace until I am knocked out).
Now came the third week. I was initially promised that those handling the front-end will give me a Vue.js front-end. No Vue in sight. Instead, a HTML5 UP theme was inserted into our stack. I continued to connect the controller actions to Blade, Eloquent, Facebook. It is as though the first two weeks did not exist for some of my team mates. Well, that is fine..., as long as the page is not as bare as my own sample Blade files. (FYI: The sample Blade files are to help my team mates know what data can be fetched from the controller.)
Today I received a PR. When I first saw the diff, of course, a CSS class with camel-case and two hyphens instead of one is going to trigger my convention-o-meter. And so I asked my team mate about it in the WhatsApp group. I then went back to further review the PR. There was one breaking change and one instance of untidy indentation.
Whether CS3216 cares about code quality does not diminish the fundamental discipline of writing good code. If we seem to have "no time" for that, it simply means we ought to have spent "more time", even if it means sleeping later than 10.30 PM.
I was told to not be "nitty picky" by the PR author even though she is trying to submit programs that are prone to human error, and wants me to "merge" it because we have "no time" (original phrase was "at this stage"). She told me to change those violations myself if I am "so particular". Moreover, she claims that my argument "has [nothing] to do with discipline" just because I (the back-end person) am not going to use it. I told her that our other team mate who is going to work on front-end is likely to have problems. She changed subject and told me to go help the others.
In a normal week, I allocate 2 days to lessons, 1 day to deal with tutorials and labs, 2 days to research, and 2 days + x number of additional hours to CS3216. The 2 to 3 days for CS3216 this week have ended. I will be unable to help those team mates until Monday night.
I am feeling more stress than needed. This is so unfair. What is wrong with trying to protect my other team mates from bad code? And those changes are not even difficult to do.
4 comments | Leave a comment
Tuesday, 29 August 2017
This week, we had Prof Damith and TA Su Yuen for our lesson. Prof Damith taught us how we can prepare for our presentations next week (the app seminar), while TA Su Yuen taught us what to consider when building our product.
Prof Damith mentioned a couple of acronyms. PUMA, WIIFY, and so on. However, the only things I can remember right now are do-believe-know, WIIFY, benefits instead of features, and finishing strong. Prof Damith used Apple's product launches as a case study. The launches often involve telling the users what they can do with Apple's products (watch videos for long hours, for example), instead of overly technical descriptions that are measured by bits or bytes. I guess this means that people are unable to translate the features into benefits in such a short time.
For do-believe-know, Prof Damith mentioned lectures as an example of "know". It is thus crucial that our presentations motivate people to do something about the apps we are presenting. Doing that would also catch the audience's attention, as they will need to listen to know what to do.
Finally, the most important point of Prof Damith's presentation, in my opinion, is WIIFY. I always switch off when I feel like there's "nothing in it for me", so I understand how important it is to hang that bait in front of the audience.
The only problem is, the only reason why people should listen to us in the app seminar would be the 1/9 chance of them having to critique us.
TA Su Yuen discussed about things to consider when designing an app, and, of course, how important designing is. She proposed several versions of mock-ups, which I think is agreeable. However, I feel that designing in digital form is really not my cup of tea. Plus I will end up spending more time learning about the prototyping software itself too. I usually stop and move on to programming after drawing a few versions of pen and paper designs.
Su Yuen also discussed about empathizing with the user. Her talk really came in too late. Would have been nice if she came to speak on our very first lesson. All these design thinking skills, we always "learn" and then forget to put them to real practice.
In my opinion, the most important thing I learnt from Su Yuen today was the number 3. The maximum of 3 things to do per screen. I was using oBike phone app (without unlocking anything of course) for the very first time today. There were so many tiny buttons that do pretty important things. There was a "!" button that was for reporting faulty bikes. However, "!" also means "info". And that was just the beginning of some huge confusion with the oBike UI...
I look forward to building minimalistic but powerful apps in this module.
3 comments | Leave a comment
Monday, 21 August 2017
Principles of Software Engineering (Colin)
The main takeaways: Design is very important, no need to use fabulous frameworks, start everything early and stay early, learn to prioritize, users are (almost) king. Most of what Colin said was a refresher to me because it is really high-level understanding. Really eager to hear something more specific and technical. E.g. Walking us through the process of designing a specific type of (simple) app or API as a case study. Or conduct a comparison or evaluation between frameworks or libraries with similar goals.
Breakdown of roles
ArchitectureColin says we need one person in-charge to coordinate the input of the other team members (e.g. technical proficiency).
ProgrammingThis is a very small part of software engineering. As the projects in CS3216 are non-trivial (must be production-ready), we should not jump into programming right away. We should first design and plan our application. This reduces the number of times we create breaking and expensive changes along the way.
DocumentationColin also emphasizes the importance of documentation. We are not likely to remember what we have programmed some time ago.
FeaturesIt does not matter what your technology stack is. Create something which solves somebody's current needs (more people if possible, for a user base and potential business model). We must empathize with our target audience.
Graphic AssetsDesigners should consider expanding their skill set beyond Photoshop. For example, Illustrator.
DocumentationNon-programmers should still be familiar with the product and be able to write user guides at the minimum.
SalesConducting sales and branding will not only help increase and diversify user base where possible, but also curate more customer feedback and experiencing general responses.
Two non-programming roles
Designer and/or marketingA person who plans the brand and design of the app is essential in bringing in users and feedback from the perspective of a potential user.
LeaderThe leader is in charge of dividing the work, follow-up with every assignee, and conduct user testing on the product.
Different software development life cycle (SLDC)
The waterfall modelStep 1: Requirements analysis (produces a requirements document book)
The business analysts will gather all the needs and requirements from their clients and document their findings and possible designs.
Step 2: Design
Based on the requirements, plan the system architecture and tools to use.
Step 3: Coding
The plan in Step 2 is implemented. User tests are implemented here as well. The code base is rectified accordingly.
Step 4: Testing
This is where the user acceptance testing (UAT) happens. The client will test the product and provide feedback. If the client is unhappy with our product, we will not get paid. The vendors (which is us) will then return to Step 3 to work on the client's feedback.
Step 5: Maintenance
Produce any other relevant programs, scripts, or documentation which aid maintenance.
After a few years, the product becomes obsolete, and the whole cycle repeats.
Disadvantages of the waterfall modelThe only constant is change. The client might have changed his requirements, or insisted that we got his requirements wrong (perhaps we were really wrong). Within our "company", the waterfall model causes us to suffer from late integration and late testing because we do complex things one-by-one, and there is a lot of idleness.
Agile processThe agile process consists of stage-by-stage development, ranked by importance. The more important and core features are implemented first. With each iteration, more features are added. However, every iteration produces at least an MVP.
The agile process is an extremely rapid switch between the stages of the waterfall model, except that the amount of requirements, design, and code increment gradually.
This process is not just rushing. It teaches us to prioritize features while remaining flexible to changes.
Disadvantages of the agile processThis process might not be thorough and thus not fast enough to create highly scalable applications as there is a lot of communication involved between people in the team. I.e. Agile is very difficult to execute in a very large organization where there are a lot of communication barriers (many people in between).
Guidelines for our assignments
- Big dream
- But rank the features
- Look at your team (make use of their proficiency)
- Look at the clock
Designing an app
We need to decompose the app into several components.This reduces complexity, as we may not understand immediately how to solve the problem, but we can make use of abstractions.
We also need to divide the work, and use each other's code just by knowing the interface or specification.
Typical levels of decomposition
- Sub-systems (e.g. a system of micro-services communicating with each other)
- Layered hierarchy (e.g. inheritance, module imports)
Modules should not make assumptions about other modules. Some ways to maintain low coupling include no global variables, no mode variables to change the behavior of the method.
Colin emphasizes the need to validate the produce live constantly. In my experience, deployment can be a pain (different server, different environment, etc.). This causes me to look through all sorts of error logs ranging from bash, Nginx to the web framework itself.
Colin pointed out that the change of the model is very likely to cause breaking changes on the controller and view.
Database schema design
In NoSQL, there are no relationships. This means the tables are de-normalized (add redundant copies of data since there are no relationships). For non-trivial applications, the redundancy is significant and confusing, disorganized.
Resist feature bloat
We can rank the features, but keep the core feature ranking at the top consistently. This ensures we actually complete the core features. The "new" features may be helpful, but they should still be ranked below.
Consider a separate alpha deployment. Ensure nothing breaks.
Respond to user feedback
Respond selectively. If no other users care about this feature, perhaps we should implement the other more important features.
Backup user data
User data is priceless. If time permits, we should take a look at one-step restoration methods (in addition to AWS snapshots) like Ansible.
Start with pen and paper
While prototyping tools create beautiful and professional mock-ups, we might get distracted by learning the prototyping tool itself (i.e. where to change this part, that part, etc.).
Hi I'm Chris and I'm here to talk about Scrum (Chris)
Chris clarified some of doubts regarding product owner. I had the misconception that both the product owner and the scrum master are the leaders of the team. The backlog concept is new to me, but I cannot appreciate such overly-elaborate planning. I can at most look forward by 1 or 2 releases, not a whole product backlog. My previous company does weekly Scrum but without organizing sprints. Maybe that was why I got blocked for way too damn long. And... a sprint of 3 days sounds inhumane to me. I prefer having all 5 working days and grabbing stuff over from the next sprint if need be. Feelings do not matter, but they still affect us.
Roles in Scrum
Decides what will be included in each of the releases. Somewhat like a client and more of a requirements person.
Ensures progress and does the communications to meet the product owner's expectations. Could be part of the team as a developer or designer. Somewhat like a project manager.
Developers and designers who also play a part in the design and features. They are the main implementer the actual product.
Epic (or user story)
As a (role), I want (feature), so that I can (benefit). From this statement, you know who wants this feature. You have a name for this feature, and finally, you know that this feature has a purpose.
A list of features and what ought to be inside for all versions, including future ones. Rank features by must-have (high), nice-to-have (medium), bells and whistles (low). Release backlog is for past and current releases.
Estimate the time taken for each feature and put them into sprints.
3 days to 1 week. The frequent checkpoints ensure progress is made and resolve blocked tasks as a team.
Daily scrum: Stand up meeting (15 minutes)
At the start of the day, everyone answers 3 questions: What I have done last week, where am I blocked at or need help with, what do I plan to do this week. This is what I did at my previous company. The meeting usually lasts for 30 minutes because there are more than 10 people.
1 comments | Leave a comment
Monday, 14 August 2017
I hope to learn:
- Making something really useful and sufficiently complete, unlike my personal side projects
- Experience the whole process of design and implementation
- How to engineer a product in a team, instead of doing it alone
- Different perspectives from people about UIUX
- Discipline in creating quality products
- More about various frameworks and libraries, and the philosophies behind them
- More about Facebook API design and usage, never managed to understand such APIs (including Google's) back then
- To find and correctly implement or debug programs based on the answers from the internet
0 comments | Leave a comment
Sunday, 26 June 2016
For the whole of yesterday and half of today, I was at the HDB Cool Ideas Hack 2016. My team is "HDB Crawler".
Our project aims to connect HDB residents to HDB through an event organiser system.
The residents will be using the mobile application to find out about upcoming HDB events, past HDB events, and HDB events that they are going for. They may RSVP to upcoming events, or submit feedback about past events in the same platform.
The HDB administrators will be using the web application to manage events, changes of which would be reflected in the mobile application accordingly in real-time. They may also view feedback from the residents pertaining to any particular event, and gauge an overall rating through Watson's sentiment analysis.
The source code for our mobile application can be found here. As for our web application, it is currently with my team mate Ashish.
Below are some websites that I was browsing through during the reception before the prize presentation:
And now, I will be back to my usual lifestyle, but with a sweet shift of how I am going to pursue my dreams.
0 comments | Leave a comment
Wednesday, 22 June 2016
Once again, somebody has complained about my website being too personal and thus unprofessional. Hence, I have decided to conduct a CSS overhaul here.
- Replace background image with background-color
- Remove border, font-size and line-height increase for a:hover effect
- Remove Google fonts import
- Update font-family to Helvetica
- Update font-size and line-height for every heading, paragraph, body or class
- Update image width to 100% for every post
- Update profile and milestones (renamed to "The Hacks")
- And probably one or two more tiny updates I left out
Will be creating a whole new repository out of this source code.