nus-se-script
commented
3 weeks ago [IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]
Team's Response
This report relates to the UI layout and design of application that our team has chosen. From our understanding of the report, the tester suggests that instead of creating contacts and assigning projects to contacts, we should be creating projects instead, and then assigning contacts to projects. This is a matter of user preference.
ArtHive was intended to be a contact management app and should be used as such, and hence we have rejected this report. We did not intend to create a project management app as the tester suggests.
Even if it is to be considered a valid report, we think that the severity should be very low as it is purely cosmetic and does not affect usage.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: ## Summary: I deem that this report remains response.Accepted and severity.High.
Thank you for the comments. However, I disagree with the replies, and explain them below:
I think the original message, although short because of the duration of the exam, was sufficiently clear and was not misinterpreted by the team.
From our understanding of the report, the tester suggests that instead of creating contacts and assigning projects to contacts, we should be creating projects instead, and then assigning contacts to projects.
Target audience
Firstly, it should be noted that the term used by the team "artists" in their UG is vague. Artists here can refer to many different types of artists "painters, sculptors, photographers, musicians, dancers etc.". I have previously reached out to Prof Damith regarding this issue but did not get a response. To give the development team the maximum benefit of the doubt, I will use the in application demonstration to scope out what they define as artists here.
Indeed, it does seem that they are catering to various artists, not just a specific type. As such, the scope of artists should and will be deemed flexible in the following arguments.
Purpose of the application
The stated intention of the application is to "manage clients and commissions". This is indeed a valid value proposition considering how a single artist may be engaged with multiple clients at any point in time. As such, an application that is centralized to track all of their work would help streamline their workflow and organizations, considering how different clients may prefer to use different platforms for contact (email, Slack, Discord, Whatsapp, Telegram, etc.).
However, it should also be noted that the development team is inherently proposing a new application in existing to all applications that the user is using. This is already an uphill battle as the product should be deemed sufficiently useful and important for the user to want to use it in the first place.
Contact management app or Project management app
The development team did not explain why ArtHive was intended to be a contact management app. The only apparent reason that can be generated without assumption is that this was due to the requirements of the team project which was to extend upon AB3, which is a contact management app.
Following the scope of what defines a FeatureFlaw, which the development team has agreed to:
I am indeed arguing about the fact that due to the nature of their target audience, their application is flawed in terms of their design, and should be project oriented contact management instead.
It is much more intuitive for artists to organize their work around projects / commissions, not contacts. A single commission can involve multiple stakeholders (and thus clients) (eg. HR for contracts, finance for payments, development team for specifications, ) etc. This would be much more relevant for artists that are constantly engaged with large companies (photographers, web developers etc. which are definitely intended to be catered to by the application as seen in screenshots above). The current design of the application forces the user to:
- Create duplicate project information across multiple contacts
- Manually track which contact is responsible for which aspect of the project
- Risk inconsistent project status updates across related contacts
- No way for the user to search contacts that are associated to the same project (the
findfunction supports onlynameandphone).
* No way for the user to make meaningful associations on their own within the application (for example the addition of a `Remark` for each contact to provide a link to the company communication channel etc. which was provided free to us as an AB3 tutorial).This design choice forces the user to memorize every single key point of contact, even within the same project (seeing that you can only search for a contact either via their name or their phone number). This could scale to very large numbers considering the fact that artists may accept long term commissions (ie. recurrent events, long term projects spanning years). This is thus inherently a design flaw as it brings huge inconvenience to users.
Ultimately, this intentional design choice by the development team leaves crucial information fragmented across multiple contacts. Moreover, the fragmentation of data and potential inconsistencies in information (ie. if the user forgets to mark the project as Complete on one contact but not the other) forces the user to manually check the project status on their own. This drastically increases the likelihood of errors in commission management and generates unnecessary complexity in managing multi-client projects.
All of the above issues can be solved just by changing the design to a project oriented contact management application. Contacts can still be easily found (and in my opinion, much more easily) , and associated contacts all have natural groupings. Commission information that are shared across the same contacts can be updated together in a single command, and users do not have to memorize every single name relevant to a single project. Consider the most simple case scenario:
I am working as a UIUX designer, and thus has to lias with finance for payments, and the lead developer to vet their designs. Since they have different contact information, I add them into ArtHive as separate contacts. In the event that I wish to contact the lead developer, but lost their contact details...
(Development team):
1.Search for the HR contact, see the name of the `project` which I have named it under.
1. Hope that I named the project consistently for the lead developer's contact
1. Manually scroll through all existing contacts within ArtHive to find the same project name
1. Obtain Lead developers information. Evidently, the more contacts you add to the same project name, the harder this becomes.
1. This extends to other use cases: for example if I finally got paid for the commission by the finance department, I have to manually check through **every single contact that are related to the same project to update the payment status**. Else in future, if the user forgets if the commission has been paid for, they would have to manually tack through all contacts again.(What I am suggesting it should be):
1.Search for the HR contact, see the name of the `project` which I have named it under.
1. Contacts are associated by project, I am able to **easily locate these relevant contacts**.
1. Obtain lead developers information.
1. All other issues that are on a project level are easily accounted for, it only needs to be **updated once**.User preference
Evidently, this is tied to the nature of the artists work, and should not have been downplayed as "user preference" as stated within the development teams response. This emphasizes on the fact that the development team does not fully comprehend the nature of their targeted audiences work.
As such, from the above arguments and analysis, it seems relatively clear that if compared to an application that is project oriented, users would naturally stand to benefit from that much more than the current design choice provided by the developers. This classifies as "features that don't fit well with the product" as it provides severe inconvenience to the users. Moreover, considering the fact that this is a design flaw that is a core component of the system, this does not quality for NotInScope either. As such, this report should be Accepted.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** ### Core functionality of design This is a severe downplay by the team into categorizing as a cosmetic issue, which as explained above, is an inherent systemic design flaw of their product. In fact, this could be argued as a shoehorning of their product to meet the contact management nature of AB3, which further suggests that the development team has not considered the needs of commission-based artists which is a **severe issue**. As described above, this design flaw is a **core functionality of the application** that affects **all users**. This severely disadvantages the use of the application when it comes to liasing with multiple clients for one project, making the application clunky and distasteful to use in these case scenarios, which are likely to be very common for certain types of artists (eg. those working in UI UX are likely to be commissioned by companies), all of which are supposed to be catered for as evident in their UG. Basic operations becomes unnecessarily complex and requiring duplicate inputs, and there is a complete lack of workaround in the current design of the implementation. This makes the product significantly less useful for its core purpose, fundamentally undermining the utility of the application as a contact management application for clients and their commissions. All the flaws that arise due to the design choice by the developer team for making it a **contact management application** instead of a **project oriented contact management** app severely inhibits proficiency in artists workflow, and poses as a huge disincentive to incorporate this application to be used if compared to a replica of the application except for the fact that it is project oriented. In fact, in common use cases (see the examples provided in disagreeing to the development teams response), there is fair grounds for arguing the application is in fact unusable as it poses too much hindrances.  Thus the severity of this issue is **high**, not **veryLow**.
Projects that require communication with larger companies / more than one contact would find it very difficult to use the application, even if planned enhancements allows for search by project. For example, if I have multiple points of contacts with a company (HR for payment and the team itself that wants the art), I will need to create two separate contacts and know who to get in touch with.
The creation of contacts is fundamentally flawed as the point of contact should not be the unique one, but rather the project itself. Names of projects can be highly similar in nature and even with the planned enhancements there is no way to tell provided the user itself records a unique identifier (eg. COMPANY-PROJECT-NAME) and this is inherently itself a feature flaw.