Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web page raw outline #203

Closed
wants to merge 2 commits into from
Closed

Web page raw outline #203

wants to merge 2 commits into from

Conversation

herrbischoff
Copy link
Collaborator

This is a first draft for a development base of the website.

@iCHAIT
Copy link
Owner

iCHAIT commented Nov 27, 2015

Hey @herrbischoff , this looks some pretty cool stuff. You can surely proceed with this :)

@iCHAIT
Copy link
Owner

iCHAIT commented Nov 27, 2015

The only problem is that I am not very much familiar with the tech stack you are using so I am afraid how much I will be able to contribute, however I feel things would get better when we have our first developed version :)

I am really excited for this 👍

@herrbischoff
Copy link
Collaborator Author

@iCHAIT: Good to hear that you like it! :) The stack is really pretty straightforward once you dive into it. I'll be happy to answer any question you may have about it.

So, now we should discuss layout/design. Do you have any reference pages you like for me? They don't have to be anything like what we are trying to build, just impressions and inspiration. I'd like to get a feel for what kind of layout you like, colors, composition, style, ... You get the idea.

@herrbischoff
Copy link
Collaborator Author

BTW: did you get my email about collaboration?

@iCHAIT
Copy link
Owner

iCHAIT commented Dec 4, 2015

@herrbischoff That sounds good, also it would be a good chance for me to get some web development skills up my sleeve 👍

As far as content for inspiration is concerned for our design page, the guys at ZEEF contacted me as they were interested in making a front end page for the same and this is what they created. I think it is simple in look and feel, and contains all the relevant features such as a comment box, options to be able to share the webpage directly on Facebook, twitter and google plus (I really like this one), moreover it provides a capability for the owner of the list to add/edit content directly via the web page itself and lastly a suggestion feature for the visitors.

I think the guys at ZEEF have got most of the features covered up, it is just the design/layout of the page that I am not very much impressed with.

Though this can definitely serve as a foundation for our web page.

Your thoughts?

@iCHAIT
Copy link
Owner

iCHAIT commented Dec 4, 2015

And I didn't receive any mail from you side.

@herrbischoff
Copy link
Collaborator Author

That sounds good, also it would be a good chance for me to get some web development skills up my sleeve 👍

You're welcome.

I think it is simple in look and feel

Well, I'd say the page you liked to is rather crowded — especially header and footer. ;)

and contains all the relevant features such as a comment box, options to be able to share the webpage directly on Facebook, twitter and google plus (I really like this one)

Alright, so easy social sharing should be possible. No problem.

moreover it provides a capability for the owner of the list to add/edit content directly via the web page itself

This is a big one. We have two possibilities here:

  1. The involved one. Linking the GitHub repo Markdown file up with a web application hosted somewhere else. This cannot be done in plain JavaScript (to be hosted by GitHub Pages). It needs either a separate server like shared hosting with PHP or to must be done in React with a Firebase connection to hold the GitHub authentication data that obviously should not be available to anyone. This would be more of a web application than a website.
  2. The straightforward one. Separate the repo and the website. This needs hosting elsewhere as well and will have no direct connection to the repo whatsoever. It would require double data entry: once on the repo and once on the site. Therefore the downside is that data will get out of sync. If your main focus is the web site, this poses no problem though.

In any case, there will be additional data which is not contained in the repo that needs to be stored somewhere.

In conclusion, the main question is: what is your main focus for the list — website or repo?

and lastly a suggestion feature for the visitors.

That could be easily implemented using a mail form, which — again — needs a server of some kind.

I think the guys at ZEEF have got most of the features covered up, it is just the design/layout of the page that I am not very much impressed with.

I'm with you on that. The design/layout is nothing to write home about. We could go with a Material Design approach if you like. It's clean, modern and works especially well on mobile screens. Compare: http://www.getmdl.io/components/index.html

Usually I create pages mobile-first, from smallest to largest screen. This way you are forced to focus on the essentials for mobile and only add non-essential parts on the larger screens, which most often results in cleaner and faster-loading results overall.

@iCHAIT
Copy link
Owner

iCHAIT commented Dec 4, 2015

👍 for the mobile-first approach, it makes a lot of sense.

👍 for material design approach as well, it definitely looks cool, and the site working as expected on mobile screens on the go is definitely a big plus.

This is a big one. We have two possibilities here:

  1. The involved one. Linking the GitHub repo Markdown file up with a web application hosted somewhere else. This cannot be done in plain JavaScript (to be hosted by GitHub Pages). It needs either a separate server like shared hosting with PHP or to must be done in React with a Firebase connection to hold the GitHub authentication data that obviously should not be available to anyone. This would be more of a web application than a website.
  2. The straightforward one. Separate the repo and the website. This needs hosting elsewhere as well and will have no direct connection to the repo whatsoever. It would require double data entry: once on the repo and once on the site. Therefore the downside is that data will get out of sync. If your main focus is the web site, this poses no problem though.

Currently I am not 100% sure about this, the first approach definitely seems to be the better one as all the data would be in sync, and it would not require us to make double entry every time a new entry is made, but as far as I can see it would require a lot more effort to create such an application which doesn't seem to be worthwhile for our use case (which is a essentially providing a front end for a markdown file).

On the other hand the second option seems more trivial and easily achievable, but data synchronization is a big issue, and double data entry would definitely prove to be a hassle.

@herrbischoff I believe that I am correct in my thinking.

@dufferzafar What do you think, which approach would be better here?

@herrbischoff
Copy link
Collaborator Author

It would be far easier to implement 1. if the GitHub repo was the one source of data entry. Comments can be hosted externally (Facebook, Disqus, whathaveyou), sharing and all that jazz can be done in HTML and JavaScript while suggestions are still tricky. Especially with regards to preventing spam. Also, there's the question of mail server credentials that would need to be stored somewhere. All in all it's a big hassle, so I suggest using comments for that.

And yes, your thinking is clear as a spring morning. ;)

@iCHAIT
Copy link
Owner

iCHAIT commented Dec 8, 2015

@herrbischoff I think we should go with 1 as you have mentioned it is easier to implement, moreover I really like the fact that the repo and the web application would be in sync as far as the data is concerned and it won't require us to do double data entry.

@dkhamsing
Copy link
Collaborator

@iCHAIT should we close this or keep it open
what's the status of the web page effort

@iCHAIT
Copy link
Owner

iCHAIT commented Jul 14, 2016

@dkhamsing The PR is stagnant, I wanted to work on this but I don't see myself working on this in the immediate future due to lack of time, though I'd love to see this PR getting merged sooner or later, I think @herrbischoff should make the final call on the future of this PR as I suppose he has already put some significant effort into it.

@herrbischoff If you are interested in working on this, please do, otherwise you can close it down.

@dkhamsing
Copy link
Collaborator

@herrbischoff can you comment on this

@herrbischoff herrbischoff self-assigned this Aug 9, 2016
@herrbischoff
Copy link
Collaborator Author

Right now I've got little time to work on this but will eventually. I've just assigned the issue to me so it pops up in my global issue list. It's low priority for me right now but not forgotten. I already have a quite firm idea to implement this in Vue.js down the road.

So in essence, I'd leave this issue active.

@herrbischoff
Copy link
Collaborator Author

herrbischoff commented May 27, 2017

Just wanted to let you know that quite possibly I'm going to have some news about this in the coming weeks. The idea is still using Vue.js, the application will therefore be reactive and the functionality fully client-based so it can be hosted as a GitHub page quite nicely. This should prove to be a nice little exercise. :)

I will create a new branch for the page along with a new pull request to discuss the result.

@iCHAIT iCHAIT closed this Mar 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants