Sketch of WelcomePage/Home/ProcessStore/ProcessDetails

[amarbajric]

Frontend (currently named ExecutionPlatform) needs design sketches for following pages:

• WelcomePage
  • The page after Login which more or less greets the User
  • Concept can be like we know it from Amazon (newest processes, popular processes, ..)
• HomePage
  • Dashboard for the User where he can check for information about himself or access further functionality like My uploaded processes, Balance, My organization, ...
  • should be a rough outline and just show how we could structure it. Think about possible functionality which can/will be implemented.
• ProcessStorePage
  • The page where a user can search for processes and gets all processes from his search result.
  • Can be linked with the WelcomePage (like in Amazon to present search-bar and as soon result comes back present another page with results)
  • Think about components which may be helpful for this page (i.e. Filter component at the left side, etc..)
• ProcessDetailsPage
  • This page represents one individual process if clicked on it at the ProcessStorePage
  • shows all details of a process and further options like buying it, reviewing it, etc..

What to consider:

• Do not redesign the whole frontend.
• Keep the current design in mind and create sketches upon the current layout/design.

This task does NOT require a PR. Only review and approval needed. If done, upload the file to the SharePoint and post a comment with a reference to it!

[AlexanderLichtenegger]

Platform-Processstore WelcomePage sketch.pdf

[amarbajric]

Review

• no description found
  • short description is needed either in the document or in a comment under this issue
• file was uploaded via waffle
  • check out other issues which do not need a PR, and you will see that everyone is pointing to our SharePoint
  • Therefore, file is rejected. Please remove it from the comment and upload it to the SharePoint with a proper reference (see other issues how its done)
• insufficient documentation
  • why do you want to redesign the whole frontend? we only need a layout for the landing page! This means the basic layout of the current frontend should stay like this. You should craft a sketch which is based on the current layout of the frontend
  • IF however you have found some reasons to redesign the whole frontend, you have to document this. Therefore, sketch is rejected from my side!
• insufficient work
  • I think the initial draft (on the first page) is insufficient. You need to document it better or make a better draft/sketch. I cannot accept this!

ToDo (for @AlexanderLichtenegger ) I have updated the title and description of this issue. Therefore, the following things need to be done:

• Revision of the posted Welcome/LandingPage as it is not sufficient
• Create sketches of other pages which are mentioned in the description of this issue
  • also include a documentation in the file. This is important since we need to know what considerations you have had during the creation of the sketches.
• Delete the currently submitted file as it should NOT be uploaded via Waffle.
  • If done, upload document on the SharePoint.

[tortmann]

ad Review by @amarbajric (quotes below refer to this, above, comment)

no description found

Agree

file was uploaded via waffle

Agree with @amarbajric , honestly I couldn't believe that you didn't even manage to correctly reference the document. There are only a handful of extremely simple things to keep in mind especially when working on issues that don't require pull-requests (PR). All documentation need to be put in the respective folder on the SharePoint platform. The next time I will not even open the link, just fyi. Therefore file is rejected.

insufficient documentation

Unfortunately I also have to agree with @amarbajric here. Did you even take a look at the existing frontend design? Redesigning the entire frontend makes no sense in my opinion, however if you want to do it nonetheless you need to come up with a much much better solution than the one you uploaded and furthermore provide arguments why we should redesign in the first place - this would then be discussed further in a meeting. The goal is to build upon the existing project and extend its funcitonalites and not throw aside their code and design to start again with the design you suggested in the sketch (which is a complete joke and not adequate for any IT related masters degree, but we will get to that in the next point) Therefore, the sketch is rejected.

insufficient work I cannot accept this!

In my opinion this draft is more than insufficient and absolutely unacceptable. This can not have taken you more than 30 minutes if we are being honest here. Furthermore there is a complete absence of any reference to required components (Angular components) which should definitely be mentioned and mapped to the respective parts of the pages.

ToDo (for @AlexanderLichtenegger )

All ToDos are approved by me and are to be finished as soon as possible or latest by Friday, April 20 to be discussed during the weekly scrum.

I would like to add here that the estimated time for creating the new sketch, as decribed in detail by @amarbajric in the inital task description, can realistically require no more than 3-4 hours of work, since you are just supposed to build upon the existing design and extend it with our new functionalities (components). This should definitely be possible since you already had a look at the current version and should be very familiar with the current design.

[deKilla]

first draft: https://fhjoanneum.sharepoint.com/:f:/s/EBUSA-Projekt/Et6Xk9dcivtGplI4xUHGc5gBabu3zg49dX89BfL_RupOzQ?e=M1bkFf

[tortmann]

I just want to mention that the following should be considered for all pages: The specific display logic should closely related to the user type - e.g.: a normal user of an organization would not need to see any Process review related content etc. A filtered view based on the logic we decided on during the identity mgmt implementation should be considered for every page. This does not really require a change in your design but should just be considered during the implementation phase.

ad WelcomePage - MIDDLE

I think it is a great idea to list trending processes as a mean of marketing. Latest could include process from the last month or week (depending on the upload frequency) - Trending could make use of the rating system.

ad Dashboard

Same as mentioned above - user type related display logic of all content. (e.g.: under review only for users that can upload processes and are actually waiting for a review)

ad ProcessStory

There isn't really anything to add here. Everything seems fine and the desgin is very straight forward and matches our requirements. Maybe the Processes' rating should be displayed on every grid/card element in the top left or bottom right corner since you also considered it for the filter functionality.

ad ProcessDetails

I agree with displaying everything that is relevant all the time - since as the name suggests - this page should display details. However we should consider the same as for the pages above - user type related display logic of content.

Adapting the button (bottom right) and what it does should be adapted depending on the status of the process for the logged in user (already owned - Start/Stop etc.) as you mentioned.

I think however that we should limit the way that the process owner can modify the pages look and feel and only offer the possibilty to adjust what information is displayed beyond the minimum information - this should ensure a consistant design troughout our platform imo.

Thank you very much @deKilla for the fast completion of the task. In my opinion some small textual adjustments which were mentioned above and might be mentioned by @amarbajric should be added to the document but besides that the task is APPROVED from my side.

[tortmann]

I just read the PlatformFunctionality_v1 document and realized that I forgot to mention that the ProcessDetails page requires a comment functionality. This functionality should also be considered on the Dashboard for reviews of not yet approved/reviewed process models since the review process requires a comment functionality.

[amarbajric]

Thank you for your extensive review @tortmann. I think he has already covered a lot of points. However, there are some points which I have to mention. Note: The sketches/points I have not mentioned are accepted from my side!

Welcome Page TOP LEFT

• a user cannot start processes. He can only upload his and interact with the ProcessStore. Everything related to starting/executing/viewing processes (that are instantiated) should be implemented in the Dashboard of the organization BOTTOM
• great idea. Maybe we should discuss if we should shift this section to the top? But its just a suggestion from my side

Dashboard

• As @tortmann mentioned we have to consider which type of user is interacting here. Is it the normal user? Or is it a user who is currently on the Dashboard of the organization page?
• In this case, we cannot mix currently running, stopped, under review and approved as only normal users can upload processes and get reviewes or approvals for it. On the other hand organizations can buy processes and configure > instantiate them and furthermore should be able to monitor them.
• The right hand side is a neat idea, but it should be considered as HD (highly desired) or even optional. Anyways nice idea.

Process Store

• I like the sketch of the process store a lot!
• Only thing to mention here again is, that processes are uploaded by users ONLY. So the by Fantasycompany123 would show a username and not an organization.

Process Details

• a process will NEVER be shown in the process store if it has not been approved yet. Keep this in mind as you suggested to show this information. ONLY the approver and the uploader will interact during the review phase with the process. If it gets approved, it will be published in the store.
• As @tortmann already mentioned, we also need a commenting section, where organizations can rate the process (i.e. rating 1-5 with optional comment)
• Again you mentioned "...is owned by the user...". A user cannot own or aquire a process by design. This would violate the concept discussed in the data model adaption file!

ToDo

• Please check out the data_model_adaption_v2.pdf under /Development/Data_model/ on the SP!
  • Upon this, refactor the mentioned points.

For example:

• User can ONLY upload processes but not buy them or instantiate them.
• Processes are not published until approver has approved the process.
• Organizations CANNOT upload processes but only buy them.
  • ONLY orgs. who have bought a specific process can also rate the process (spam protection)
• ...

TL;DR: Take these points (found in the data_model_adaption_v2.pdf) into consideration, and adapt your documentation ONLY (just some bullet points for clarification. You can also refer to the proposed data model file). If done, the task is APPROVED and we can finally start to implement the pages. Thank your for your first drafts and documentation. Great work so far!

[deKilla]

v2 is up - https://fhjoanneum.sharepoint.com/:w:/s/EBUSA-Projekt/ESpFBr3Mt4BMmeclRIGpCNwB2oo-W84U6z9Tt8F0vSC-CQ?e=xEcBxP

I had trouble with the wording and confusions regarding "user" and "company" - I hope I was able to resolve all those issues.

ad WelcomePage – MIDDLE That was my idea, however, if you want to know what is trending you would need more than just the current rating – i.e. some kind of rating history with a rating snapshot periodically ...

ad WelcomePage – BOTTOM Discuss the positioning as suggested by @bajroo

ad Process Details I know that a process under review will never be in the store, however, the creater should be able to access the details page in order populate the description, images etc. before it is approved and published.

edit: I removed one of the points that I wrote early while I was still confused about user/company - I forgot to delete that sentence before posting it sorry

[amarbajric]

Thank your for the refinement @deKilla. From my side it is approved and very nicely done. However, I would suggest to discuss this topic on Wednesday 25.4.18 at our meeting. The discussion should just clarify some minor considerations, like the ones you have just mentioned.

ad Process Details I know that a process under review will never be in the store, however, the creater should be able to access the details page in order populate the description, images etc. before it is approved and published.

• Nice idea. I did not think about that and it would ofc make much sense. I also want to include this and the other points, that are left open, in our meeting on Wed 25.4.18 to discuss it.

[tortmann]

Thanks for the refinements @deKilla!

I created a new version of the document - v2.1 - on the ShP where I replaced all metions of the word company with organization as it better reflects the naming conventions in other documents, but that's just a small thing.

I also had a look at the changes and could only find one small thing that should be optimized and added to v2.1 of the document. In the ProcessDetails MockUp image you are still using a the organizationName instead of the userName. This should be adapted to match the ProcessStore page.

Overall I think it's very well done and thank you for the quick completion and refinements.

Nice idea. I did not think about that and it would ofc make much sense. I also want to include this and the other points, that are left open, in our meeting on Wed 25.4.18 to discuss it.

@amarbajric - I agree!

[deKilla]

@tortmann I am not sure what you mean regarding the ProcessDetails MockUp ... it says created by Hans Hohlwig (a user) and there is a comment from Fantasycompany123 (a company that is using / has bought this process) ... please clarify thank you

[tortmann]

@tortmann I am not sure what you mean regarding the ProcessDetails MockUp ... it says created by Hans Hohlwig (a user) and there is a comment from Fantasycompany123 (a company that is using / has bought this process) ... please clarify thank you

You are correct I did get that mixed up, sorry about that, however are organizations really able to comment? or rather users within certain organizations - something like: johnDoe:organization123

maybe @amarbajric can shortly comment on the ability of organizations to write comments

[deKilla]

I thought, that it is a user (that is part of a company) who writes to comment, but it is the name of the company that is displayed ...

edit: a user might theoretically change the company he's working in, but the company that bought the process remains the same - @amarbajric decides or we discuss it in the meeting

[tortmann]

I thought, that it is a user (that is part of a company) who writes to comment, but it is the name of the company that is displayed ...

I am not entirely sure, off the top of my head, if we have even decided this use case yet. Any solution is possible it's just a matter of deciding on one (if not done already) imo

[amarbajric]

maybe @amarbajric can shortly comment on the ability of organizations to write comments

See comment below.

I thought, that it is a user (that is part of a company) who writes to comment, but it is the name of the company that is displayed ...

A user, who is part of an organization, is able to:

• buy a process (if he/she has the suited role)
• rate processes the org. has bought (if he/she has the suited role)
• ...

rate processes the org. has bought (if he has the suited role)

In short, the user, who is within a specific org, can comment (post a rating). The display logic can be discussed. But it is a good idea to make something like

Good process. We like it!
***** (5/5)
commented by johndoe (org123) on <date>

[tortmann]

In short, the user, who is within a specific org, can comment (post a rating). The display logic can be discussed.

Then we shall discuss this during the next meeting (25.04)

[amarbajric]

Then we shall discuss this during the next meeting (25.04)

We can ofc discuss this point. However, I think it is absolutely mandatory to display the organization name. The name of the user, who has rated the process on behalf of the company, can be optional. So we can implement something like this:

• commented by johndoe (org123)
• commented by org123

[deKilla]

We can ofc discuss this point. However, I think it is absolutely mandatory to display the organization name. The name of the user, who has rated the process on behalf of the company, can be optional. So we can implement something like this:

• commented by johndoe (org123)
• commented by org123

We should, however, consider the case that a user changes their company. The field should not be updated in that case.