What I am looking to do is to have a main page with a list of 20 or so photographs on it. When one of the images is clicked, I'd like it to open a new page with the description on that photo, a preview of that photo, and the option to buy it. Is the only way to do this is by writing a new page of code every time a new image is clicked, or is there a way every page can share the same code, while only changing the preview of the photo.
I believe that what you say can't be done with a front-end language, it requires more of a CMS to do such thing, requires back-end job with an engine (PHP as example) and database such as MySQL.
Please remember that the HTML is a Markup-Language not a programming language, it has no logic as "if and else"..
I hope that answered your question. <3
I work for telecom company in India. My work involves checking the connectivity of the network through IPs and the ping through it. Our company has a website http://117.239.43.170/ping_select.aspx for it. The problem is the website isn't mobile friendly and I need to zoom in and out every time I go to that site. I am familiar with the basics of front end. I have created the mobile friendly version of that website and stored it in my mobile, but it is redirecting me to the same website. So my question is, is there any way I can use a mobile friendly version of that website and still get the same results
I recommend you making an android application and control (send and receive) the website in the background. This website uses a HTML form and very few inputs so it wont be that hard to go with the java staff.
Alternatively you can make a browser plugin for your phone browser to control the website in background and at the front end you get your desired UI.
I guess you dont have the access to upload your website to that server so you cannot request to your BSNL server from a local website (or whatever else). The BSNL server wont allow cross server requests. The best bet you can make is layering below that website over any other programs.
What would be the best way to handle this situation?
Company has two types of products, therefore two seperate webpages to serve up each:
products-professional.html
products-consumer.html
Company changes structure and now does not want to list products as seperate, new page is:
products.html
According to Google Webmaster Tools, some sites have links to our old pages. I've added a redirect on them to point them towards the new page, but the errors still show in Google Webmaster Tools. I don't want errors.
You should:
monitor GWT errors and add missing redirects
try to contact as many as possible users linking to the old url's and ask them to fix it
Since 2'nd point is hard to achieve in 100%, your redirects has to be bulletproof, and even then google can find some weird urls from a year ago and report errors.
I have a navbar, and in it right now I have links to various blogs on my site. I have that same markup throughout my site on all pages.
Here is the thing, when I start growing my site, how do I scale something like this? Right now, I have been going to each and every html page, and doing a copy/paste anytime I need a new link to it or something similar.
I'm sure there is a better way to do this.
so a s per the comment's above there is a slew of ways to go about doing this. One possibility, would be to keep each link as a varchar as well as possibly a title that you want to display for each blog post that would be displayed in the nav bar. then you could build your nav bar dynamicaly each time using a scripting language such as php, python, perl, nodejs etc. Im not sure if node.js will be supported by godaddy but undoubtedly the other would be. The approach you take will be a personal choice based on if you control when user upload content (like an administrator) or if uploads can happen freely. if you plan for uploads to happen freely you will most likely want a dynamic approach, However if You plan to have an administrator to oversee each new entry a static approach could be used and called to regenerate the nav. bar each time a new post is made available. Again, if you need some help getting this started you know where to find me!
-best of luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Designing a web application, how do you design the main page? By this I mean the page that is displayed to a user after entering the base url, like http://www.foo.com.
It would probably depend on a website, but...
stackoverflow welcomes us with list of questions, no silly what is stackoverflow landing page,
last.fm prestens a kind of dashboard, being very popular lately, kind of personalized landing page for registered users
google welcomes us with a search box, but iGoogle i completly diffrent story - looks diffrent for everyone (well, and that's the point actually).
The other thing is, if the user is logged in (provided the website supports logging in), should we present him a diffrent content there then some new, random incomer? And I don't mean some personalized content, but something completly diffrent, like his user profile instead of main page?
From one perspective it could be good - registered users usually know our site, and get a kind of special greeting as soon as they come back. On the other hand, this could cause problems - when I show a website to a friend, then he goes there from his computer and sees something totally diffrent.
And other thing is, when I show a http://www.foo.com to a friend, and it takes me directly to my user profile / dashboard - this isn't sometimes what I'd like to show everyone, as this might show some of my personal data, etc.
What do you do when you design your web applications? What's, in your opinion, best from user's point of view, do my concerns about the website looking diffrent for registered and unregistered users do or don't make any sense? (Again, I don't mean small diffrences, like hiding huge register now link - but showing completly diffrent view then).
It really depends on the focus of your application, but if you were to generalise I would say determine the one or two most critical paths in your application and focus on those.
Registration is probably what you
want to drive more than anything
else, so make it clear how users can
sign up and get involved.
Make it is easy for existing users to sign in.
Consider the amount of text you have
on your front page and reduce and
pair it down as much as possible. Keep the messages and information you
convey here as succinct as possible.
Provide some content immediately
showing what your application or site
provides. Don't make users follow a
link to access the core functionality
of your site immediately e.g. if
you're building an auction site,
ensure there are listings on the
front page.
Consider your audience. If your site is non-technical, the fewer UI elements you present the better. Portal like sites, with lots of compartmentalised functionality and information can be confusing and overwhelming for many non-technical users.
Make it clear how users can get Help if they require it
Without knowing the business area of your site then it's going to be tricky to answer this, but...
You should get the user into the main flow of your website as soon as possible, and the home page is the best place to do this.
If you're an online store, start showing your products.
If you're a search engine, give the user the ability to search.
If you're a blog/news site, show the user the latest news.
Yes - make the experience for a logged on/registered user better (show them THEIR news, show them their recommended products etc), but the purpose of your site should be obvious and accessible from that home page. Get your existing users into their flow as soon as possible, and attact new users in to your site by showing them the meat of your site.
There are plenty of places out there that discuss good web design, making your site "sticky" etc. Check out SmashingMagazine.com (it's one such site) but there are plenty of others.
Oh, and remember that there's one very important user of your home page that you need to accomodate - search engines. Make their life easy, make the content discoverable and indexable, and drive people to your site via Search.
What I've found works best for me is to "role-play" the end-user's experience.
When they initially hit your site, what do they most want to see, or in other words, what are they most likely to be looking for and wanting to do?
I work on many intranet websites for a very large company, and what I've learned is that a home page that has detailed information of the site and what it does is useless and, consequently, my end-users just skip over it in order to get to the pages that they really need. So, my strategy usually consists in a home page that allows them to get straight down to business and whatever they're there to do.
BUT, that's just for the sites that I create. I think it totally depends on your target market and what they're wanting to do.
For the most part, a visitor landing on your page will already know the gist of what your application is about, so there shouldn't be a need to explain in detail what is is you do. Instead, show them that you have the information they are looking for. Screenshots and screencasts are becoming popular these days as a means of getting this across to the short-attention-spanned user.
For registered users, I'd recommend taking them directly to the primary application page instead of the homepage (unless the homepage is the primary application page). For many apps this is a Dashboard (Flickr, Basecamp, Campaign Monitor). If your app's main focus is the homepage, you may want to show them a personalized version of that page (think Google vs. iGoogle).
With all this said, it really does depend on what you are building. Every application is different and there's no right way to do it - only conventions that work for most.
I would start by looking at the type of tasks that can be performed inside your web app, what's important? what's important when they are a new user? what's important when they are a repeat user? what's important when they haven't even registered yet.
Although all of these things happen on the the same page, it's likely that you'll need to define different states. e.g. If a user is on the homepage and not logged in, should we prompt them to login and register.
Perhaps also look at Personas so you can figure out exactly who will be using the app and what is relevant to them.
It should be whatever makes sense for the application, and this should be verified by testing the application with a group of expected users.
The main page should provide a first-time user with enough visual and/or written information to understand what the application is about. They should have some idea as to what actions they can take to interact with the app and what the outcomes of these actions could be.
I know people hate this answer on stackoverflow but there's only one way to find out what the most appropriate thing for your users is - you need to brainstorm ideas with potential users or at the very least you ask them.
I'm not suggesting that you do a focus group, or put a flawed poll up (neither of those things work). Rather, I'm suggesting that you go out and talk to people who will potentially be in your target users and do planning games with them (like card sorting) or go out and do some user testing with paper prototyping.
Anything else is guessing.