Show links from the posts in the sidebar

[maxceem]

From @vikasrohit

We want to identify that if user has pasted a link to a file or a general hyperlink in a post/thread. And if we identify while user is writing the message, we would create a proper object of link or file in our system so that we can render that link or file in the left bar of the project. We can treat the title of the thread as title of the link/file and the actual URL typed/pasted by the user as URL for the link/file.

[maxceem]

As I understand we have to choose a way how we would determine if the link we have pasted should be treated as a link or as a file.

Most likely we would have to download the linked resource and check its mime type or something like that.

Do you have any other ideas from the top of your head?

[maxceem]

@vikasrohit

1. If we detect that link leads to a file it looks like we would need to download it and upload to S3 bucket which may take some time. As an alternative we can change our attachment implementation in project service to support third-party links to files. It would make this feature almost instant, but such links to files could get broken if files are removed in these third party locations. What do you think?

   actual URL typed/pasted by the user as URL for the link/file

   Looks like here your intention is to update the attachment implementation to support third-party links rather than re-upload them to our S3 bucket.

2. If we edit post and change link, should we update respectively link or file?

3. if we edit post and delete link, should we delete according link or file?

4. We can treat the title of the thread as title of the link/file

   One topic may have many posts inside and every post may have several links inside. So it looks like there would be multiple links/files with the same name. We can try to use several ways of determining more link/file name using the next mehtods if you like them:

   1. If we have a "downloadable" link to a file with defined Content-Disposition it may have a filename defined inside this header: Content-Disposition: form-data; name="fieldName"; filename="filename.jpg" so we can use it as file name.
   2. if we don't have filename inside Content-Disposition, we can check if the URL is ended with something which looks like a filename with an extension: <filename>.<ext>
   3. if URL doesn't have it we can still try to use the ending of URL for the filename, but it may looks very bed like https://tpc.googlesyndication.com/simgad/2536338633819292849. So probably in such case we should use the topic name. But we can still try to guess the file exntesion by the MIME type from Content-Type header, for example image/png - > .jpg.
   4. if have to use topic name for link/file name and we already have the same name we can add a number in the parenthesis to the name, like:
      
   5. Another way would be to let user define file/link title using interface of the Drat.js post editor. This may require additional thinking about how to do it form UX point of view.

   Let me know if you would like to have any of these ways to handle file/links titles.

[RishiRajSahu]

@maxceem my thoughts on above, so there are two parts of problem, what we need & how to achieve

what we need

1.If its a web URL and target for the url is file, it doesn't needs to be downloaded implicitly via code & then upload to s3 as file, it will be treated as link only not file.
2.If user is pasting link, whose target is file/webpage/googledoc we just have to identify that link and style it, alternatively user can use draftjs upload icon to provide title to that link then we are good anyway.
3.If its a local machine path which is user is pasting(this will be the case when user copies file on local machine and then paste it to editor), we have to upload it to s3 and keep it as file entity(it will be link only which on clicking downloads/opens the s3 file) - Futuristic, not for now
4.Above point(3) also applies to the case when user drags and drops, if we are including that as well.
5.We are showing just files in the left panel not the links. We have to show both
6.About naming files-links or normal links, agree with you there could be multiple attachments per topic, maybe we need designers help here, one of other option than you mentioned could be
a. Showing an accordion with topic title and under that showing all its attachments, named as uploader firstname-dd-mm-yyyy-HH-MM for eg. - maxceem-08-04-2019-15-22

how to achieve
as per me having all the above points the main task is, how to detect the link and link-type(web URL/ local machine URL), I will explore more about it, you can also drop your thoughts on this.

[maxceem]

as per me having all the above points the main task is, how to detect the link and link-type(web URL/ local machine URL), I will explore more about it, you can also drop your thoughts on this.

As per your input I understand there would be 3 cases:

• we paste a link (URL) - no matter where URL leads to we will add it as a link. We can additionally try detect its type (general/googledoc/github/image/pdf) to show an icon
• we can implement drag & drop functionality for files
• I guess we can also implement copy/paste functionality for files, so user can copy some file on local machine and paste it to the editor which would trigger file upload

We cannot support such a case:

• local machine URL - we cannot trigger file uploading by pasting local machine URL. Browser doesn't let us access local machine files by their local URL.

detect the link and link-type

Regarding this we can use the next approach:

• request link header data using HEAD request (example curl -v -X HEAD https://github.com) and check two properties:
  - Content-Disposition
  - Content-Type
• If Content-Disposition is attachment then we treat such a link as a file.
• If Content-Type is text/html, then we have a link to an HTML page, otherwise, we can treat such a link as a file. And we can use the value of Content-Type to determine what is the exact type of file this link leads to https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types
• Additionally, for some common use application like Google Docs, Github, Marvelapp we may use URL domain to detect if this is a link to some of these services to determine which icon to show.

[RishiRajSahu]

@maxceem yeah the cases mentioned are appropriate. I will get back to you after having a word with product team on this, which is about, whether we should upload a file to S3(it will require to have access mechanism with all team members) or simply always treat a URL as link(avoiding upload) ?

[maxceem]

Update from @RishiRajSahu:

I have a confirmation that for now we have to just detect links whether they target for google doc/ image/ etc. we simply detect the link and ask user for title, once user saves the post the formatted link by us will be visible under left side links section. So, we don't need to download any file and upload to s3, and attaching files will be a different task which we anyway have to achieve sooner.

1. Should be adding titles to the links optional or mandatory?
   It feels that we cannot enforce users to add titles to the links. There could be situations where it's not comfortable:

   • user pastes a text with multiple links (asking him to define the titles for all the links could be uncomfortable)
   • a user enters/pastes one link, but he could be in the flow of writing post, so interrupting him to enforce adding a title to the link may be distracting. As it's one of the best practice of writing texts: first write a draft without correcting anything to pour out the main idea and not forget your thoughts and after go through the text and improve it.
     So I think adding titles to the links should be optional. We can decide what to do with the links without the title:
   • add them as URLs
   • try to generate link title in some way:
     • we can use post/phase title like Front-end phase II (2)
     • maybe some other

2. UI to add/edit/delete link

   • currently, we can select text inside the post and add a link URL:

     

     But we cannot add a link text if we have link URL inside the text

   • as we want to add titles for link URLs which we already entered/pasted I think it would be the best to use the same approach as used in Google Docs.

     

     In Google Docs we can do both ways, see demo video https://monosnap.com/file/XXyKuYdpJSMRccPzuOcDnKIxOJSXBD
     

     • we can have a text and add a link URL
     • we can have a URL and add a link text to it (change the text of the link from URL to text)
       This way we can the same UI/UX if the user starts from link URL or from link text.

3. Should we add all the links to the sidebar or no?
   If not all, how should we select them? Should it be automatic or user can control which links to add to the sidebar?

4. detect links whether they target for google doc/ image/ etc

   Should we show link types (icons) on the sidebar and/or inside text editor?

[RishiRajSahu]

@maxceem
1.yep, we can make it optional but how to decide when to ask a user for adding title or not ? And wrt to optional approach I am fine with adding default link title with topic name along with timestamp OR user's topicname-firstname-timestamp.
2.
-yeah, let's leave existing draftjs feature as it is
-yep, we can go via google's way of doing this
3.All links added to the post will be shown in left side bar
4.We can skip this for now but can create a separate issue for this to keep track of it.

[maxceem]

@RishiRajSahu

2. -yeah, let's leave existing draftjs feature as it is

   I think if we implement adding links using Google Docs way, we should remove the existent feature, as a new feature will replace all of its functionality.

3. Here is one thing I'd like to discuss. If we go with the same way it's done in Google Docs, then the text of link will be same as link title. See example:

   

   So if comlitely copy the approach in Google Docs, then the default link text (and title) would be the same as link URL.

   

   What if we keep it like that? Default link title is link URL.

   Alternatively, we can define the default link title/text another way, then as soon as we enter or paste link we should update it's title/text:
   

[RishiRajSahu]

@maxceem
2.So you are suggesting to remove the existing option of draftjs, yeah I agree like there will be multiple UX for links. Okay we can remove/hide the draftjs option.
3.

Default link title is link URL.
I think if we are using approach suggested by you and showing the popup when link is detected and putting default title as link URL we can ignore the custom title of topic-name-timestamp

What about making link title update optional ? when do we show it and when do we not ?

[maxceem]

There are two general things:

• Link text should be the same a link title if link text is defined.
• We will create links in the project when we will send/update a post (not during the editing)

1. So user can just enter link like this without link text, only URL:

   
   In this case, we didn't add link text, so means we don't have link title. What we can do here is during user saves such post we will create a link in the project with some default title for such link, like topicname-firstname-timestam.

   • The question is, should we also update the text of the link inside the post to the default title we created? Or leave the link as a URL? (I prefer to leave it as URL)

2. Another case if a user created a link and defined the text for link:

   

   In this case we can use the link text as a link title.
   The possible drawback of such approach that inside our posts we can use the same link text. For example, we can create several different links to challenge specification, they all will have the same title in the sidebar but lead to different challenge specification.

3. If the user didn't initially didn't' provided the link text, he can do it by clicking on the link and use UI similar to google docs:

   

@RishiRajSahu What do you think?

[maxceem]

From my comments above looks like making link text same to link title maybe is not a good idea and we should make them different. Though it would make the UI more complicated as we will need to introduce one more field to edit title. So when creating a link user would define link URL, link text and link title.

[RishiRajSahu]

@maxceem overall looks good, find my response inline below -

The question is, should we also update the text of the link inside the post to the default title we created? Or leave the link as a URL?

Yep leave it as URL, as updating it inside the post will affect the readability of the post, we will improvise on this feature depending upon the feedback we get after release

they all will have the same title in the sidebar but lead to different challenge specification.

I think that's fine, as it will be upto the user how they want to name their link, maybe later in future we will at a check to compare the new title with existing title before saving. OR if you think we should add this right now ? Anyway, I am fine with the possible drawback you mentioned.

he can do it by clicking on the link and use UI similar to google docs:

How user will be driven to this ? I mean, how will user know that he can do such operation of adding title to link ?

[maxceem]

How user will be driven to this ? I mean, how will user know that he can do such operation of adding title to link ?

When the user puts the cursor on the top of the link there the popup should appear same like in google docs with two buttons, edit and remove:

• clicking remove just removes the link

  

• clicking edit would show editing popup:

  

I think that's fine, as it will be upto the user how they want to name their link, maybe later in future we will at a check to compare the new title with existing title before saving. OR if you think we should add this right now ? Anyway, I am fine with the possible drawback you mentioned.

The only drawback I see with the title same to the text is if we want to make links in posts like: here, challenge, this link and so on. So we want to use text which is simple and good for post message, but not good as a link title for the sidebar.

But if you think it's ok for now, we can give it a try and add an additional field for a separate link title later if we see that users create many simple links like these.