Jump to content

chibineku

Members
  • Posts

    1,278
  • Joined

  • Last visited

Posts posted by chibineku

  1. I hear you on the design front - I haven't got an artistic bone in my body. The only site I've made so far, which isn't launched on the proper domain yet, is sinaesthesia.co.uk and it's very basic and square. My mum, who the site is for, is happy enough with the style, and having given me no input except that she'd rather square edge tabs than rounded ones, hasn't got any recourse if she wanted a fancier looking site. Even though it's plain, I think it's clear and things are in the right place (canonical alt nav links, logo, login tray, horizontal nav, three col layout and footer).

  2. I have a problem with the registration process: where do I put the number that was e-mailed to me? There's no space for it on the form. The site isn't very attractive, but as an exercise in database retrieval it seems to work just fine. It's a little uninspiring though. The 'registration' link is hard to see.

  3. I like the point ApocalypeX makes about running a website like an app. The iPhone lets you create shortcuts to websites and to view and interact with them exactly like apps. On other smartphones there is the intermediate option of creating widgets which are applications written in web languages which are then packaged to run like apps. I have only the slightest experience with them and only on BlackBerry, but they offer more flexibility than normal native apps because you can update the web content and the widget will always deliver the newest content. A big problem with Apple apps distributed normally through iTunes is that if you need to release an update it can take several weeks to get approval, and approval for your update can be rejected on any basis that Apple likes. So users may get very disillusioned and think you don't care to rectify any problems they've stumbled upon. Widgets and websites stored as apps will reflect the newest content always. However, charging for them is more of a gray area. The sponsorship or paid service route is going to be your avenue for revenue (hey, that's pretty good marketing speak) instead of the pay-per-unit distribution of, say, Apple apps. Note that there are books on turning websites into apps in XCode on an Apple Mac, so those of us who are into web dev and scripting can turn our skills to app creation with very little additional learning. An excellent guide is Building iPhone Apps with HTML, CSS, and JavaScript by Jonathan Stark.

  4. It beggars the belief of most who know it, but we use AOL and have done for a long time. In the last 6 months or so, I have started getting mailer deamon e-mails saying that e-mails I've sent have failed to be delivered. The problem is that I didn't send the e-mails. They are to addresses that were auto-added to my AOL address book and that I've had no occasion to contact for a long time. I've contacted AOL a few times and their helpful suggestion was to change my AOL password. Great, but they already have my e-mail address and my address book and I'm starting to get replies from businesses who are receiving these spoofed e-mails. A stroke of luck is that I finally received one of these e-mails myself and have got the server headers. I am not sure how to decipher them, though. If anyone could help me or point me in the right direction, I would be very grateful. I will of course send the headers to AOL too. In full, they are:Edit: headers removed as they exposed e-mail addresses for further spamming. I didn't have my head on straight when I posted them.

  5. I don't think that's a problem, per se. A login form is usually viewable by navigating to it through the history or by direct address input, but just because you're seeing it doesn't mean that you're signed out. I assume you are storing login data in the session and/or through cookies? As long as the session or other cookies are set, you can skip over the login form without filling it in because you are not destroying the session/cookies on the form page. The script that handles the form submission to login should destroy the session and clear any login cookies before setting new ones, though.

  6. Mobile phones tend to have proprietary ways of accessing such data, and you have to register to a developer program before you are authorized to use the JavaScript methods necessary. For BlackBerry smartphones, you need to pay $20 for a username, password and code signing keys so that you can test and deploy apps using the secure API. For iPhones, you pay more ($100 or so) to join the Apple Developers Program, giving you access to the XCode IDE and allowing you to test apps using the hardware APIs. I haven't explored any other platforms, but the registration process seems mandatory so that any abuses of the hardware can be traced to the developer. Once you have the right permissions, the access is via JavaScript and is very simple to use. For example, on a BlackBerry, accessing the GPS position is as simple as:blackberry.location.latitude or blackberry.location.longitudeThere is very in depth documentation available on the developer pages of the relevant sites.

  7. Can I see controller.php? It might help, I think. The redirect is being handled in an OOP style, which is not something I use much so I'm not sure if that's a native method or one defined by the previous developer. You can always perform your own redirect instead of the one your predecessor used so that the thank you page will appear as long as you want and then redirect to somewhere else.

  8. The problem is going to be on index.php, somewhere in the code that runs if the page action = 'thankyou'. So we'd need to see that, really. You can do a timed redirect by echoing a location header:<meta HTTP-EQUIV="REFRESH" content="0; url=http://www.yourdomain.com/index.html">The '0' is the number of seconds delay you want, i.e. how long the page on which the header is echoed will be visible before the relocation happens.

  9. It doesn't matter at all if the link is created before the page element. On clicking the link, logic dictates that the browser checks the DOM for a suitable element to bring to the top of the page and at that point if it fails to find it, either display an error or just do nothing. I think that's more graceful and useful than giving you some sort of runtime error as soon as a link appears referencing an element that isn't there.

  10. If your rewrite rule is adding .php to all file requests, then image files, css files, javascript files, etc. will all have an extra .php appended to them if your rule is not specific enough. For example:

    RewriteRule ^example.com/(.*)$ /example.com/$1.php

    would be a poor rule and would cause problems.

  11. I think it looks good, very professional. There are a handful of markup and CSS validation errors, but these are the work of half an hour to fix. The way the product menu slides down is a little unsteady, I don't know how to make that smoother, but it's not a big deal.

×
×
  • Create New...